Hi Flavio, 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. /Markus On September 19, 2015 6:38:59 AM GMT+10:00, Flavio Curella <[email protected]> wrote: >I'm not sure if this warrants a DEP, so I've decided to post it to the >list >first. If this needs to be a DEP, just let me know and I'll follow the >DEP >process. > >Rationale >------------- > >Assume the following scenario: > >1. At some point in history, project A was deployed in production and >was >very successful. >2. The project created a table called `transactions_log`, which is now >considerably big and full of very valuable data, that we want to >retain. >3. Because of $reasons$, project B gets started as a future replacement >of >project B >4. Project B wants to reuse `transactions_log` and the >`transaction.models.Log` model unaltered > >What we have is a 'split' between what the initial migration for the >`transaction.models.Log` model should do, between dev and production: > >* On local dev, it simply creates the table >* On production, the migration must be faked. > >Traditionally, we would go to the person in charge of migration and >tell >them 'Hey, migration `transactions.0001_initial` must be faked'. >But this seems error-prone. That information ('fake this one specific >migration') could be lost in the communication workflow, and imposes >the >cognitive burden of having to remember another special case. > >Proposed solution >------------------------ > >Assume the following settings files: > >``` ># settings/local.py ># ..usual list of settings... >``` > >``` ># settings/production.py >MIGRATION_FAKE = ( > ('transactions', '0001_initial), >) >``` > >* On `django-admin.py migrate --settings=settings.local`, the migration > >`transactions.0001` will be faked only if the `--fake` flag is passed >(previous behavior). >* On `django-admin.py migrate --settings=settings.production`, the >migration `transactions.0001` will *always* be faked. The new setting >will >act as an ad-hoc, per-migration override of the global `--fake` option. > >I have a branch up as a Proof of Concept at >https://github.com/fcurella/django/tree/feature/adhoc-fake (no test or >doc >changes yet). The code change necessary seems to be minimal, let me >know if >you think it's something worth having. > >Thank you, >–Flavio. -- 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/12F5779F-E1C9-4473-AF92-B52851465694%40markusholtermann.eu. For more options, visit https://groups.google.com/d/optout.
