Running syncdb in --no-south mode (with patch)

[trebor74hr@…]

Real-world example:
A) developing in dev env with dev db

• create models
• syncdb - created
• startmigration - initial ...
• do changes, startmigration new, ...
• apply migrations ...
• saving migration scripts to VCS (svn commit)

B) installing on production brand new application

• syncdb - creates tables only for applications not managed by south
• migrate
  • will create tables based on very old models
  • call every migration after it until the end

I would prefer this scenario for B):

B) installing on production brand new application

• syncdb - creates tables only for applications both managed by south and those not managed by south (tables are created based on recent models version)
• migrate --fake

That's why I suggest adding following option to south (in patch attached):

--no-south South managed applications will be synced with classic

django syncdb.

Example:

>python manage.py syncdb --no-south
Running in no-south mode ...
Syncing...
...
Synced:

 > django.contrib.auth
 > south
 > app1 [south managed]
 > app2 
 > app3

If any model from [south-managed] application(s) is created
you should check: migrate --list / --fake

then calling --list:

>python manage.py migrate --list
app1
     0001_initial
     ...
     0004_is_default_drop

calling --fake:

>python manage.py migrate --fake
Running migrations for app1:
 - Migrating forwards to 0004_is_default_drop.
 > app1: 0001_initial
   (faked)
 ...
 > app1: 0004_is_default_drop
   (faked)

[Robert <trebor74hr@…>]

patch for running syncdb in --no-south mode

[andrew]

There's a good reason South does that, and it's because migrations aren't necessarily just about the schema, and even if they are, the other idea is to have the same actions having been performed on both live and development.

That said, there's already an option with tests to do this (speeds 'em up), so I'll slate it for inclusion. Might call it --no-migrate, though.

[Robert <trebor74hr@…>]

I know that is correct way and follows the idea of south. But on the other hand there are some exceptions for which I think south should have such option (--no-migrate).

One other example, in development sometimes I drop table(s) and want to recreate them back. With south I can't do that, but with syncdb I can. This option enables this (Workaround with south: I rename migrations dir temporary, call syncdb, table is created and then I rename migrations dir back ;) ).

See also #172 which suggest better signals support in south and #171 asks for better documentation about south/django post-syncdb sending signal distinction.

[Robert <trebor74hr@…>]

I wrote new ticket #174 related to initial create/fill db, what is related to this ticket too. If you call migrate in --no-migrate mode, then django shouldn't fill db with initial db data if it is not compatible with newest models db scheme.

Conclusion:
There are 2 ways to make db from the scratch:

• create oldest scheme, initial fill (FILL-OLDEST) and incrementally run all migration until newest migration
• create newest scheme, initial fill (FILL-NEWEST) and don't run any migrations after - just mark as migrated to the newest

Fixtures FILL-OLDEST and FILL-NEWEST are different, and based on different db schemes (models). How to solve this generally, I don't have any good idea for now (have 2 fixtures is hard to maintain).

[andrew]

OK, I'll look into these; currently my internet is very spotty, and exams are round the corner, so don't expect uberquick response times.

[Robert <trebor74hr@…>]

Just FYI - I think I found that this procedure can be used for creating FILL-NEWEST fixture:

• one can use sqlite :memory:
• start the whole south migration on it - create tables, FILL-OLDEST fixture, one by one migration ... to the latest
• dumpdata on this sqlite :memory: to some file (e.g. initial_data_newest.json)

This file (initial_data_newest.json) is FILL-NEWEST fixture.

[andrew]

Replying to Robert <trebor74hr@…>:

Just FYI - I think I found that this procedure can be used for creating FILL-NEWEST fixture:

• one can use sqlite :memory:
• start the whole south migration on it - create tables, FILL-OLDEST fixture, one by one migration ... to the latest
• dumpdata on this sqlite :memory: to some file (e.g. initial_data_newest.json)

This file (initial_data_newest.json) is FILL-NEWEST fixture.

An interesting idea, but it sadly won't work; SQLite doesn't support all database operations at the moment, and even if it did, people with DB-specific migrations are going to expect those to work.

[Robert <trebor74hr@…>]

Interesting blog which uses trick explained before:
​http://ericholscher.com/blog/2009/jun/11/migrating-test-fixtures-using-south/

Just like explained in prev. comment, sqlite :memory: can't be of use in general case, but using your own db for getting new fixture from initial one, can be of use in some occasions.

Maybe it is not bad idea to explain such scenario in documentation (wiki) or link is just enough.

[andrew]

Implemented in [f7a99186f275].