You are right, they are not 100% clear as I am still not 100% clear how they will be used in the end. Maybe pending_bbid and accepted_bbid would be better names.
2024-07-29 21128, 2024
monkey[m]
I don't mind a verbose accepted_entity_bbid, even
2024-07-29 21153, 2024
kellnerd[m]
I've just drawn a table with all possible scenarios I could come up with because I was no longer sure whether the second BBID column was necessary at all.
2024-07-29 21126, 2024
monkey[m]
I guess if we want to be able to merge an imported entity's data into an existing entity?
2024-07-29 21149, 2024
kellnerd[m]
There are five meaningful cases for the pair (pending_entity_bbid, accepted_entity_bbid):
2024-07-29 21107, 2024
kellnerd[m]
1. (A, null) = new pending import
2024-07-29 21123, 2024
kellnerd[m]
2. (A, A) = accepted import
2024-07-29 21139, 2024
kellnerd[m]
3. (null, null) = discarded import
2024-07-29 21103, 2024
kellnerd[m]
4. (B, A) = update is pending
2024-07-29 21103, 2024
kellnerd[m]
5. (null, A) = theoretical possibility to seed the table with manually added entities which have the external identifier
I think migrating potentially existing imports into the new schema is not worth the effort, what do you think monkey?
2024-07-29 21112, 2024
kellnerd[m]
Or should I even just adapt the existing migration script again?
2024-07-29 21122, 2024
monkey[m]
I would honestly nuke whatever is there, if any (assuming there is nothing, from what I remember)
2024-07-29 21154, 2024
monkey[m]
As a matter of fact I may have nuked the tables already, or the previous sql migrations scripts were never run against the production DB, because there are no import tables
