#bookbrainz

Hello monkey ! I have finally [changed the schema](https://github.com/kellnerd/bookbrainz-site/commit/0405f96b98b8b1c7f1e02cb1e7bae5869230363d) to merge the `import` into the `entity` table.

Great, thank you!

I'm finishing a few things today but have planned to review your PRs tomorrow, perfect timing :)

While I was at it, I've also [renamed](https://github.com/kellnerd/bookbrainz-site/commit/2c5b3ef7c5c55135a53e7a1e82e4dd367227c379) a few import related columns and a table to give them more descriptive names.

Still untested as I would love to have a quick sanity check before I'm going to create migrations and update the ORM.

Yes, the renaming was a good idea, it's clearer now.

Also the right time to be doing any changes on the imports sql

Especially if you agree with the new names, I don't want to rename them in all places twice :)

s/if/whether/

Here, the difference between import_bbid and entity_bbid is not instantly clear. Is the entity_bbid used once the import has been accepted?

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.

I don't mind a verbose accepted_entity_bbid, even

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.

I guess if we want to be able to merge an imported entity's data into an existing entity?

There are five meaningful cases for the pair (pending_entity_bbid, accepted_entity_bbid):

1. (A, null) = new pending import

2. (A, A) = accepted import

3. (null, null) = discarded import

4. (B, A) = update is pending

5. (null, A) = theoretical possibility to seed the table with manually added entities which have the external identifier

Thanks, I've [renamed these two columns](https://github.com/kellnerd/bookbrainz-site/commit/495302748b91fafd576dda01614a1b4ecb1b48de) again.

Thanks for the explanation!

I think migrating potentially existing imports into the new schema is not worth the effort, what do you think monkey?

Or should I even just adapt the existing migration script again?

I would honestly nuke whatever is there, if any (assuming there is nothing, from what I remember)

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