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]> 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;
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.
