-
Notifications
You must be signed in to change notification settings - Fork 159
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
Better handling of schema change #26
Comments
Filing this as a bug. The SQL handling is all pretty crappy and could be made better. One thing I will mention here is that any fixes must work for the Mongo, SQL, and Base backends, so the canonical definitions of the models will have to be stored in either the core classes or in a new centralized module. I think the best way would be for To your last question, yes, data should be able to be preserved through schema migrations. I'm guessing SQLAlchemy has some functionality that should help us automate this. |
This is blocking the next release. Everyone that uses SQLite is going to have a shitty time upgrading unless the migration handles itself. |
Closed by f917990 |
Whoops, I fixed one issue but not the other. Reopening this until changing the model is less of a pain. |
@utkarsh2012 Would appreciate your input here, as I'm having a hard time seeing an easy solution to the model definition problems in core.py. Here's my understanding of what changes in core.py when the Task schema is updated. Let's add a new variable called
Given that these three steps aren't necessarily related, I think the only way to consolidate the process would be to add what would probably be a fairly complex config object that is capable of assigning variables to any subset of these three steps, as well as applying formatters to each individual step (e.g. Do you agree? If not, how do you think we could do this? If you do agree, do you think this path is worth it? |
I think addition of Alembic fixes a major issue of schema migration. Existing users will see a flawless migration. Regarding the changes needed (step 1 to 3) in the app after addition of a variable to a table, as you mentioned it looks like a hard problem to solve which is not really worth tackling. New variables are not really added frequently to a table, when they are added we can go through this exercise. Although it should be clearly documented some where (in developer doc rather than user doc) so that someone can hack around it quickly. |
Added a bit of developer documentation in the wiki: https://github.com/tthieman/dagobah/wiki/Changing-the-Core-Models |
If the model is changed, these functions needs modification:
In core.py:
Try to find a better way of managing this.
Also, after a schema change, I am currently deleteing the existing dagobah.db and recreating it. Is there a better way of doing this? schema migrations?
The text was updated successfully, but these errors were encountered: