Enforcing migration order (related to publisher2) #1098

Closed
wants to merge 3 commits into
from

Projects

None yet

5 participants

@evidens

MySQL wouldn't run the south migrations as they stand (mostly because of south).

I added better support to south https://bitbucket.org/beyondwords/south-mysql to support foreign key renames, but there were still lingering issues with out-of-date foreign keys.

The easiest fix I found was to enforce that all publisher2 changes in the plugins, follow the one in CMS.

I thought this would be useful to others and minimally invasive to the existing code base.

Hope this is deemed useful.

Cheers,
Gabriel

@evidens evidens Minor patch to enforce migrations follow database structure changes
When publisher2 migration in cms deletes the cmspluginpublic table
This patch forces the dependent plugins to rename in sync avoiding a
MySQL migration error in south
8e2650f
@ojii

how will this affect existing migration histories? I don't want this to break every installation... Also have you considered contributing your south fork back into the main south?

@evidens

This shouldn't affect existing migration histories at all since when you run migrate it checks in the table which migrations have already been run, not the order (or in most people's case syncdb and fake migrate). The added lines are just hints to ensure the migrations are run in an order that remains consistent with the database during the initial migration.

I did contribute them back and they are now merged into the main branch of south https://bitbucket.org/andrewgodwin/south/changeset/d310fe2fda97
The package on PyPi has not yet been updated though.

@kezabelle

Anecdotal confirmation, having cherry-pick'd: With an existing database, re-running migrate skips everything, because as beyondwords says, it just tests the south_migrationhistory table (I can't remember whether it's a hard or soft match, but it doesn't matter for this changeset). Additionally, running python manage.py syncdb --all && python manage.py migrate --fake still works, as does doing python manage.py syncdb && python manage.py migrate

I've only done so using the SQLite driver, but it should be the same across the board. Quick, get Jenkins on it!

@ojii

really sorry to only actually look at this now, but why is there javascript changes in this pull request?

@ojii

needs cleanup (remove the JS fixes from this pull request), other than that LGTM.

@yakky

Actually only beyondwords@8e2650f looks relevant while others look like github cruft.

@piquadrat

Closed in favor of #1270 which only contains the schema migration changes

@piquadrat piquadrat closed this Jun 9, 2012
@evidens

Thanks @piquadrat ! This was one of my first patches so I didn't know to branch before submitting (and then didn't get around to re-splitting it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment