Persistence layer and constants.py

Moved from https://github.com/BookOps-CAT/NightShift/pull/11#discussion_r753536408 :

The database is being instantiated from these constants right? I'm just nervous about having values in the persistence layer being externalized here, since generally having that value doesn't 100% guarantee that's what it will be in the database (again, generally).

Generally I would expect these values to be loaded from the db at runtime, but if they are being loaded/checked from here I think this works!

I hear what you're saying. That is something I've been struggling with. I hope you can steer it in the right direction.

Yes, the database is instantiated from the constants. I wanted to accomplish two goals (not sure how reasonable they are):

Prevent constant calls to the db to retrieve id or code or name whenever needed (speed)
Have a way to associate certain values (sierra format codes, tags to keep or to delete, or info how often each resource category should be queried in WorldCat) to their appropriate records in the persistence layer. These values are bound to change depending on our experiences or needs.

My thinking goes, this requires that library or resource category ids should be fixed and stable and uniform between the db and constants.py. Maybe I could explicitly enforce certain values in the tests, so no accidental change happens in the future (at least not without stopping to think what went wrong)? Or maybe a better way (as you suggest) would be to persist values from my point 2 in the db, provide a way to update them in the db, and loaded them at runtime to be used when the process is executed.

I think in my next PR all of this will be more apparent and it will be a better time to make a call here.

BookOps-CAT / NightShift

Persistence layer and constants.py #12