-
-
Notifications
You must be signed in to change notification settings - Fork 813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set up alembic migration usage #954
Conversation
This is excellent! Thanks for putting this together.
I agree. I think at least doing some basic logging of "Migration needed performing migration" / "Migration not needed" would be sufficient for now.
I think that's a common pattern for migrations, create if not exist, is fairly common.
I say we leave it for now, and cross that bridge later. Getting the initial migrations working with the existing setup is probably a better initial scope. I think we may be able to address this in another user-interactive way on the Frontend.
Yes. Yes and Yes! ✅ I don't think this is all strictly needed as apart of this PR. You can get the initial framework setup and then we can build on-top of that in future iterations and track progress in #551 In Summary - I think to get this merged I'd like to see at least some stubs setup for tests that are just marked as skip for now. That way when you, I or someone else want's to get this up to speed we have a clear idea of what needs to get tested. - What else did you want to tackle as apart of this before it gets merged? The main issue with the other PR is that it was pretty big and touched a lot of pieces of code when we didn't have many tests and the originator didn't write any tests for the work they did. Additionally, I couldn't reproduce his success on my machine so I ended up pulling out some of the parts and adding them into the main branch at the time. |
# Conflicts: # mealie/db/models/recipe/recipe.py
This eases the transition from a pre-alembic state
I've udpated the PR, including test stubs, and I think the rest can be done in other PRs:
We should wait with merging until you have finished #980, because that PR changes the DB schema quite a lot. After #980 is merged, I will have to update the |
PR #980 has been merged and I'm done with database changes until we setup alembic, so we can semi-officially put out a v1 Beta release. Let me know if you need anything else from me to get this ready-to merge. Can't thank you enough for getting this going, if you're ever in Alaska I owe you a few beers 👍 |
I think this is ready to merge 😄 I'll tell you if I'm ever in Alaska, but I owe you a few beers for creating Mealie! |
This is a WIP of setting up Alembic for migrations, as suggested in #551.
How this works: Any time you change the DB models, you need to run
poetry run alembic revision --autogenerate -m "Describe changes here"
. Anytimeinit_db.py
is called, all alembic migrations are run if the database is not up-to-date.I had to change a few imports in order to allow for alembic to find all models and have no circular dependencies.
Some thoughts of what's left to do:
init_db.py
. The question basically is: what should happen if the seed data changes? Who should benefit from these changes, and how can we achieve that?I only just found #357, so I'm not sure if I have missed anything.