[INSTRM-941] Create mechanism to manage the opDB update Created: 06/Apr/20  Updated: 12/Oct/20  Resolved: 12/Oct/20

Status: Done
Project: Instrument control development
Component/s: spt_operational_database
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: Kiyoto Yabe Assignee: Kiyoto Yabe
Resolution: Done Votes: 0
Labels: opDB
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

opDB schema is defined by `model.py` and a new database can be created by using this definition. Currently, however, there is no mechanism to update the existing opDB with records when this schema definition is updated, which happens frequently. The procedure is (semi-) automated if possible. 

Database migration tools (such as alembic) are options, but we may like easier and simpler way. Anyway, we should start from finding out what kind of options we have for this purpose.

Furthermore, we like to manage the installation of the opDB package through `eups`.



 Comments   
Comment by Kiyoto Yabe [ 06/Apr/20 ]

Just a copy from my slack comment about alembic --

I took a look at alembic ( sqlalchemy-migrate exists but people recommend alembic because sqlalchemy-migrate seems to be no longer maintained). It is basically simple and easy to use. After some setups and initialization, only two commands are basically used:

  • alembic revision --autogenerate -m "comment or version name" (to generate a migration script reading models.py and detecting diff)
  • alembic upgrade head (to apply the change to DB using the generated script)

I tested on my local opDB and found that some use-cases were good but some were not. I think we need to edit the script by hand for what we want. The generated scripts should be on the repository and tracked. I'm still not sure whether this covers all we want, but I feel this helps us for what we want to do to some extent. 
 

Comment by Kiyoto Yabe [ 06/Aug/20 ]

I have pushed my first proposal on the branch.

Generated at Sat Feb 10 16:30:14 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.