Migrations Broken With django-pyodbc-driver

[beh9540]

When running migrations on a new project using django-pyodbc-driver, migrations fail due to the changing of the primary keys from AutoField to BigAutoField in this migration because of the limited capability of SQL Server to edit an IDENTITY property.

I'm able to work around this by manually changing the migrations (obviously not preferred) but I'm curious if you'd be open to collapsing this in the future? I'd be happy to work on putting a PR together.

[jleclanche]

A migration reset seems a bit like overkill at this point to be honest :/

[synasius]

Totally agree with @jleclanche

@beh9540 you might consider using MIGRATION_MODULES setting to override migrations for the oauth2_provider app. This way you can maintain your own migrations for an external package.

See https://docs.djangoproject.com/en/2.0/ref/settings/#std:setting-MIGRATION_MODULES

[beh9540]

@synasius yeah that's what I'm doing now, but I figured it'd be worth bringing up for anyone else who might run into this in the future.

[synasius]

It might be useful to add a page somewhere in the docs about this use case to help those that need to override migrations.
@beh9540 do you think it would help?

[n2ygk]

@jleclanche @synasius We are also seeing this problem with pyodbc.

What's the reluctance about doing a migration reset? It seems like the cleanest fix. The current clutter of automigrations is messy and I don't think there's any value in maintaining history of old database structure; other than in git.

I don't see how this would cause problems for anybody, would make the package cleaner, and would solve the pyodbc problem.

Anyone who has had the package for a while has already migrated their models and new users don't need that history. Am I missing something?

oauth2_provider/migrations/0001_initial.py
oauth2_provider/migrations/0002_08_updates.py
oauth2_provider/migrations/0003_auto_20160316_1503.py
oauth2_provider/migrations/0004_auto_20160525_1623.py
oauth2_provider/migrations/0005_auto_20170514_1141.py
oauth2_provider/migrations/0006_auto_20171214_2232.py
oauth2_provider/migrations/__init__.py

[n2ygk]

@jleclanche I've been looking more at recent commits and see that in fact you have been editing auto migrations. I'm curious what the reason for doing it that way is vs. removing and making a single new initial migration that matches the current models. Is this to help users upgrade from an older installed version of the toolkit? If so, do the edited migrations lead to any problems with that? What if a user is at the 0004 level and then upgrades from there. Can the edits cause a problem?

The current migrations break django-pyodbc-azure due to AutoFields becoming BigAutoFields due to a restriction in MS SQL Server so I'm trying to understand how to solve this without having to special case every single project that uses pyodbc. One of my coworkers has in fact proposed further edits to the migrations to fix this, but I thought that was not the right way to go. Maybe I'm wrong. Wouldn't be the first time;-)

I'm just trying to understand the methodology, not criticize.
Thanks.

[jleclanche]

@n2ygk When a non-sql change happens in the migration state, django generates migrations because it detects model changes, but those aren't necessarily required.

Migrations themselves are a burden on the code; require extra maintenance, etc. I'm currently trying to wipe them off another django project which has far, far too many of them causing a lot of issues.

[n2ygk]

This is a MS SQL issue, not DOT. Closing.

[jbaltodano2019]

I have the problem "the backend doesn't support altering from/to AutoField" when adding the oauth2_provider . I've not found any solution to that issue,. can you help me with it?

[jbaltodano2019]

When running migrations on a new project using django-pyodbc-driver, migrations fail due to the changing of the primary keys from AutoField to BigAutoField in this migration because of the limited capability of SQL Server to edit an IDENTITY property.

I'm able to work around this by manually changing the migrations (obviously not preferred) but I'm curious if you'd be open to collapsing this in the future? I'd be happy to work on putting a PR together.

what your solution is? what is the modification you do to the migration file?