On Saturday, September 19, 2015 at 8:39:54 AM UTC-5, Shai Berger wrote: > > Hi, > > On Saturday 19 September 2015 14:02:38 Markus Holtermann wrote: > > On September 19, 2015 6:38:59 AM GMT+10:00, > > Flavio Curella <[email protected] <javascript:>> wrote: > > > > > ># settings/production.py > > >MIGRATION_FAKE = ( > > > > > > ('transactions', '0001_initial), > > > > > >) > > > > This sounds like a very risky and scary proposal, to be honest. The > > recommended way would indeed be to fake the initial migration(s) on > > production. > > > > Since it seems to me that this would only ever be needed once (you said > > devs should just run the migration locally and the table is too big for > > any changes) I'd probably go with the one time fake. > > > > Alternatively, as of Django 1.9 you could move the transaction log model > > into a dedicated app and disable migrations for that app. > > > > As a last resort, why not make the model unmanaged (Meta.manage=False) > and > > apply the respective operations manually with RunSQL operations? > > > > That are the ideas that just came to mind, there are probably others as > > well. > > > > My instinctive reaction was that > > A) This is a highly specialized case, which doesn't warrant framework > support; > > Other scenarios came to my mind, but I didn't mentioned them to keep the proposal simple.
One other common scenario is for when you have to run slight different SQL in production versus development, for example having to `CREATE INDEX ... CONCURRENTLY`, which is a quite common necessity. That said, if you think this proposal will encourage bad practices, I'm with you and I'd rather drop it than provide an easy way for users to shoot themselves in the foot. > B) I'd solve it (at the project level) by putting some identifying setting > in > settings/production.py, something along the lines of > > # settings/production.py > FAKE_MIGRATIONS_FOR_PROD = True > > and add to the initial migration a RunPython operation which looks for > this > setting and raises an exception if it's there. Just to make the failure > explicit -- if the migration tried to create an existing table, it would > fail > anyway. > > Note that, if the model is in its own app, migrations already have a > mechanism > in them to auto-fake the migrations of an app where all model tables > exist. > > (and note that this thread is already drifting into django-users' domain) > > Shai. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/c92af8e8-338c-4813-a5a0-fe28b978a58f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
