1076996 - Documented approach for setting up zamboni is broken now that landfill is no longer used.

Status: RESOLVED FIXED

(Marketplace Graveyard :: Code Quality, defect)

Description

[Stuart Colville [:muffinresearch]]

We are running: 

  ./manage.py syncdb
  ./manage.py loaddata init 

But then running this (e.g. via docker which has no db on first run) 

You see output like this:

zamboni_1       | UPDATE schema_version SET version = 1;
zamboni_1       | COMMIT;
zamboni_1       | stdout:
zamboni_1       | stderr: ERROR 1146 (42S02) at line 2: Table 'zamboni.categories' doesn't exist

Presumably this is because syncdb run today is going against today's model state and not what it was like when migrations were first added. 

If the syncdb command is replaced with a create table sql statement from what syncdb sql output looked like back when migration 01 was added that should start with the right tables.

Comment 1

[Stuart Colville [:muffinresearch]]

Ok, managed to travel back in time 4yrs 8 months and get an export straight after a syncdb at rev 754b065 which is when the first migration was created. 

Now I will test if importing that prior to the rest of the migrations prevents the errors.

We'll also need to work out where loaddata fits into this - I'm hoping it will be 

* Initial import
* ./manage.py loaddata init
* migrations

This way we shouldn't need to update what's added by loaddata. If it's necessary to run loaddata after migrations then we'll need to keep the data up to date.

Comment 2

[Stuart Colville [:muffinresearch]]

Mat pointed out there's a much easier approach which is to run syncdb and then fake the data migrations so they essentially jump to the most recent as if they've all been applied. Thereafter migrations are used as normal.

Comment 3

[Stuart Colville [:muffinresearch]]

PR: https://github.com/mozilla/zamboni/pull/2628

Comment 4

[Stuart Colville [:muffinresearch]]

https://github.com/mozilla/zamboni/commit/b568afc169fcbcc5f612d4baa3885f93592d5bea