-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for nullable unique constraints #184
base: azure-1.11
Are you sure you want to change the base?
Add support for nullable unique constraints #184
Conversation
Somehow I managed to only include m2m-fields instead of the other way around, this is fixed in the latest commit. However, this results in the same error as in #144 to occur, though this doesn't seem possible to avoid in SQL Server. The error that occurs is because of these models defined in the django test suite:
This is probably as good as it gets with nullable unique constraints using the currently available features of SQL Server |
This would be really helpful. I tried working around this with a migration that replaces OneToOneField with ForeignKey and uses RunSQL to create the "unique index where ... is not null" but that change in the migration gets flagged as a model change. This is a much better fix. |
Hi, is anyone working on porting this for v2 by any chance? |
We are using this in a fork here https://github.com/ESSolutions/django-mssql-backend (PyPi: https://pypi.org/project/django-mssql-backend/) |
This is similar to #43, #69 and #144, and probably fixes #14.
Unlike the other PRs which are for Django 1.9 and 2.0, this is for 1.11 but should be easy to at least Django 2.x.
Unlike #144, no migrations fail when running the Django tests. Having the constraints not apply to m2m-fields solved that issue.