Skip to content
This repository has been archived by the owner on Aug 26, 2022. It is now read-only.

fix bug 1084003 - repair migrations after attachment split #2850

Merged
merged 1 commit into from
Nov 17, 2014
Merged

fix bug 1084003 - repair migrations after attachment split #2850

merged 1 commit into from
Nov 17, 2014

Conversation

jezdez
Copy link
Contributor

@jezdez jezdez commented Oct 23, 2014

This moves back three of the original wiki migrations into the wiki app and adds a new initial migration to the attachments app that renames the tables.
It also backfills the south history table to remember those three migrations (since they are still effectively applied).
The wiki app has a new empty migration that only depends on the last migration of the attachements app, so that migrating the wiki app will run the attachements app migration first.

This also gets rid of old schematic migrations that have been applied before by running the schematic command.
Some new South migrations were added as the result of that (as replacements):

  • a new data migration in the devmo app that tries to create a default site object.
  • an initial and a data migration for the feeder app (both faked during deploy)

The migration in the users app that deleted the old and unneeded user profile related tables is not handled by exception catching, for initial setups of an empty database.

The script that is run on the dev server during deploy has been modified to run the appropriate migrate command to reset the database there.

The chief deploy script has been modified to only run the appropriate migrations when the deployed git tag is "attachments-split-cleanup" since chief runs the script from disk, not after it has pulled from git.

The puppet manifests have not been updated and instead migration steps will be provided via email to the users with a current develoment environment. The steps are:

python2.6 vendor/src/schematic/schematic migrations/
python2.6 manage.py migrate feeder --delete-ghost-migrations --fake --noinput
python2.6 manage.py migrate wiki --noinput
python2.6 manage.py migrate --noinput

This moves back three of the original wiki migrations into the wiki app and adds a new initial migration to the attachments app that renames the tables.
It also backfills the south history table to remember those three migrations (since they are still effectively applied).
The wiki app has a new empty migration that only depends on the last migration of the attachements app, so that migrating the wiki app will run the attachements app migration first.

This also gets rid of old schematic migrations that have been applied before by running the schematic command.
Some new South migrations were added as the result of that (as replacements):

  - a new data migration in the devmo app that tries to create a default site object.
  - an initial and a data migration for the feeder app (both faked during deploy)

The migration in the users app that deleted the old and unneeded user profile related tables is not handled by exception catching, for initial setups of an empty database.

The script that is run on the dev server during deploy has been modified to run the appropriate migrate command to reset the database there.

The chief deploy script has been modified to *only* run the appropriate migrations when the deployed git tag is "attachments-split-cleanup" since chief runs the script from disk, not after it has pulled from git.

The puppet manifests have *not* been updated and instead migration steps will be provided via email to the users with a current develoment environment. The steps are:

	python2.6 vendor/src/schematic/schematic migrations/
	python2.6 manage.py migrate feeder --delete-ghost-migrations --fake --noinput
	python2.6 manage.py migrate wiki --noinput
	python2.6 manage.py migrate --noinput
@groovecoder
Copy link
Contributor

When I switched my existing dev environment to the branch, I tried the first step:

(env)vagrant@developer-local:~/src$ python2.6 vendor/src/schematic/schematic migrations/
Error: Couldn't find value for 'db' in settings.py

@groovecoder
Copy link
Contributor

I tried adding

db = 'mysql -u root kuma'
table = 'schema_version'

to settings.py but next I got

(env)vagrant@developer-local:~/src$ python2.6 vendor/src/schematic/schematic migrations/Traceback (most recent call last):
  File "vendor/src/schematic/schematic", line 232, in <module>
    main(path)
  File "vendor/src/schematic/schematic", line 190, in main
    table_check(db, table)
  File "vendor/src/schematic/schematic", line 139, in table_check
    count = int(say(db, COUNT % table))
ValueError: invalid literal for int() with base 10: 'COUNT(version)\n1\n'

So I'm not sure what to try next?

@jezdez
Copy link
Contributor Author

jezdez commented Oct 24, 2014

@groovecoder Huh, that's literally the command we run in all scripts, the file in question that schematic tries to load is migrations/schematic_settings.py, can you check adding the hardcoded db and table to there? also without venv activated?

@groovecoder
Copy link
Contributor

The error happens on master too, so at least we know this PR didn't break it. I'm going to dig a bit more ...

@groovecoder
Copy link
Contributor

Okay, I did find . -name "*.pyc" | xargs rm -f and it cleared up the error. All the steps worked for me on my existing box.

@groovecoder
Copy link
Contributor

Brand new vm works too. @ubernostrum r?

@groovecoder
Copy link
Contributor

ping @ubernostrum can you get to this today before it starts to rot?

@ubernostrum
Copy link
Contributor

Looking at it now that I have a functioning repo again.

@ubernostrum
Copy link
Contributor

This looks good for me when trying both with my existing setup and with a fresh one.

@groovecoder
Copy link
Contributor

Marking not ready until we get demo studio stuff thru. Then we'll come back to this for merge + push.

jezdez added a commit that referenced this pull request Nov 17, 2014
fix bug 1084003 - repair migrations after attachment split
@jezdez jezdez merged commit 20ea79a into mdn:master Nov 17, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants