-
Notifications
You must be signed in to change notification settings - Fork 501
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
Fix Commit 943b228 #2855
Fix Commit 943b228 #2855
Conversation
Wouldn't it be better to fix mistakes in migrations in a new migration? Because editing existing migrations makes things rather complicated for people who've already run them (unless the expectation is that people re-create the world DB from scratch every time they update) and it also goes against the concept as a whole. |
You should keep your custom changes in separate sql files that you apply on top of the clean database. |
I didn't mean custom changes; I meant that people that have applied this migration already (before it got edited) won't automatically get these changes just by pulling the latest changes and running migrations again (as already applied migrations are skipped). So, currently this requires some form of manual intervention on the user's part (be that manually making those DB changes, re-creating the whole DB from scratch or whatever). It also means that users essentially have to look through every commit that was made since they last updated their instance because there could've been migration edits that they would otherwise miss. That's not very end user friendly, is what I was trying to communicate. |
Just drop the database, insert it back from the release and rerun the migrations. It takes 1 minute. This conversation has taken longer than it would take you to refresh your db. |
It's not a problem for me personally, I follow the project closely and thus notice when changes like these are made. It is potentially a problem though for people who just want to update to the latest version and expect migrations to work as they usually do in other projects (as in, they don't randomly might be changed later after they've applied them).
Fair enough, if that's the official stance on how end users should use the project, that's fine by me. |
Dropping database then inserting isn't really a good solution and takes a while. |
(cherry picked from commit a722ebb)
No description provided.