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 <s...@platonix.com> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.
