#31761: Gracefull Migration | relation already exists
-------------------------------------+-------------------------------------
Reporter: Graeme Ford | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Migrations | Version: 3.0
Severity: Normal | Resolution: invalid
Keywords: migration | Triage Stage:
programming error | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* status: new => closed
* resolution: => invalid
Comment:
> Recently we have just had to wipe and re-start our migrations due to
some hardware complications and it has come up that we cannot simply re-
generate migration files as Django will attempt to re-create all migration
files and all models from scratch. Obviously this is kicking up a
django.db.utils.ProgrammingError: relation "<Table_Name_Here>" already
exists which is not very easily fixable.
Is there a reason why you can't regenerate your migrations from scractch
and simply run `migrate --fake`?
> I could always play around with the migration files or some such and
tweak them until the migrations work but that is not ideal, especially in
a production environment. It would be more intuitive to me for Django to
check against the database whether or not any of the database tables
already exist and optionally (Maybe a command flag?), only migrate new
model tables/fields?
That's precisely what `initial` migration and `--fake-initial` do
https://docs.djangoproject.com/en/3.0/topics/migrations/#initial-
migrations. If you got to a point where your Django migrations and your
production database state diverged I suggest you start from scratch and
`--fake-initial`
> I am stuck in a situation where we maintain development and deployment
environments, each with slightly different migrations due to error and bug
fixing and the fact that the DB is not backed up to the dev environment.
As a result, we do not track/sync migration files between the two as they
would not be compatible with the tracked files in each DB.
I would advise against doing that as it's an uncommon pattern that is
likely to keep breaking in the future. If you want to keep two sets of
migrations that are different based on the environment that you are
deploying to I'd suggest you use the
[https://docs.djangoproject.com/en/3.0/ref/settings/#std:setting-
MIGRATION_MODULES MIGRATION_MODULES] setting to point to per-app overrides
in production.
I have a feeling this is more of an incomprehension of how the migration
system works so I suggest you give another read at
[https://docs.djangoproject.com/en/3.0/topics/migrations/ the migration
documentation] and start by using support channels before submitting a
feature request in the future TicketClosingReasons/UseSupportChannels.
--
Ticket URL: <https://code.djangoproject.com/ticket/31761#comment:1>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.8eac27130d096c2a50cbf4e85700a8ac%40djangoproject.com.
