If I need to take either of these options I'd tend towards Shai's one - we don't want to allow people to just disable migrations on a per-database basis, that's bound to get someone into trouble. That said, the flag is going to be weird to explain to people.
Just to establish a baseline, would you say that adding an "--update" command to makemigrations - which rolls the changes into existing migrations if it can - would solve your problem here? If that's the case, we can work towards that and figure out something simpler for the meantime. Andrew On Thu, Mar 27, 2014 at 9:03 AM, Shai Berger <[email protected]> wrote: > On Thursday 27 March 2014 01:39:53 Bernie Sumption wrote: > > > I'd be willing to keep the current contract of "things without a > > > migrations directory don't get migrated", but I suspect you're doing > > > things > > > on apps that already have migrations (which makes my reticence to add a > > > setting even bigger - if you "syncdb" an app with migrations to a main > > > database, you have forever ruined the migration tracking on it). Would > > > that > > > work? Or do you want to do this on apps which are already several > > > migrations along? (If that's the case, I suspect we might have to look > at > > > re-introducing --update, which is going to be near-impossible to do > before > > > release with the new creation system). > > > > You're right, I'm creating an app with migrations but want to be able to > > run tests without migrations when I'm mid-development. I also agree that > if > > I'm running integration tests before deployment, or a non-developer is > > running tests before installing something written by someone else then > > those tests should use migrations, so it's not as simple as "don't use > > migrations in tests". > > > > How about specifying whether a database is migrated as part of the > database > > definition in the settings module? That way a database would either be > > migrated or not, and if a developer wants to set up an alternative > > non-migrated database for development there's a supported way of doing > it. > > > > Something like: > > > > # in settings_bernie_dev.py > > from .settings import * > > DATABASES = { > > 'default': { > > 'ENGINE': 'django.db.backends.sqlite3', > > 'NAME': os.path.join(BASE_DIR, 'testdb.sqlite3'), > > 'USE_MIGRATIONS': False, > > } > > } > > > > I think a flag on the test command would be much more appropriate for the > use- > cases you describe -- we don't want to send the message that disabling > migrations in tests is ok for a setup, although it may be ok for a given > test- > run (basically, like running test for just a single app is ok). > > Shai. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/1520941.Sdtj0HqCMr%40deblack > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1up9G8OO5uC%2Bw9dsnQfPng%2B_HaPr%2BHoj1PgMcgBsBsy2gg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
