#24178: Moving production data to a new database
-------------------------------+--------------------------------------
Reporter: liwee | Owner: nobody
Type: Uncategorized | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by carljm):
I do think it's odd that `migrate` will auto-fake your initial migrations
if it sees that the tables already exist, as documented in the "upgrading
from South" section that liwee quoted. I would think that situation should
raise an error instead. I see how the auto-fake behavior is convenient in
the upgrade-to-1.7 scenario, but as liwee points out, it's making some
hard-to-justify assumptions. I think it should require a special flag to
trigger that behavior.
(Of course it would be nice to keep the auto-fake behavior AND verify that
the db state actually matches the models, as liwee suggested, but I don't
think that's practically feasible at all.)
I'll look into this more to verify that I'm not missing anything and
perhaps file a new bug to require a flag for auto-fake.
--
Ticket URL: <https://code.djangoproject.com/ticket/24178#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.140745f63c4f060f90132a18c1c17535%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
