Accept deferrable kwarg for schema editor SQL #86
Conversation
|
This patch helped me to resolve issue #63 |
|
Please rebase this against master and fix the failing tests on Django 2.2 and 3.0 |
|
@OskarPersson sure, can do. Will be into next week some time when I’ll have an environment to work on it |
davidjb
force-pushed
the
deferrable
branch
3 times, most recently
from
4883a50 to
6275ca6
Compare
This follows Django 3.1.x's lead in adding `deferrable` as a keyword
argument to the `_create_unique_sql` function, following their
implementation in the schema editor object. Without accepting this
keyword arg, migrations will crash like so:
```
...
File "lib/python3.8/site-packages/django/db/backends/base/schema.py", line 360, in add_constraint
sql = constraint.create_sql(model, self)
File "lib/python3.8/site-packages/django/db/models/constraints.py", line 118, in create_sql
return schema_editor._create_unique_sql(
TypeError: _create_unique_sql() got an unexpected keyword argument 'deferrable'
```
This also adjusts the implementation to call
`self_deferrable_constraint_sql(...)` with the deferrable arg; in this
backend's case the return value is an empty string (like it is currently
hardcoded). Essentially it's the same result but allows flexibility if
this backend ever supported deferrable constraints.
Backwards compatibility is maintained by checking for the passing of a
deferrable keyword argument to the create sql function (not provided on
earlier Django versions before 3.1) and that the database backend
supports deferral for unique indexes.
|
Rebased the PR and tests are now passing on 2.2 and 3.0. Had to add a version number check since the Statement constructor requires |
|
Thanks! |
|
Thanks it worked for me |
|
Can you create a new build and update the package at https://pypi.org/project/django-mssql-backend/ ? |
This was previously accepted to the original repository in ESSolutions/django-mssql-backend#86. Backwards compatibility for Django < 3.1 is maintained by not directly trying to load the supports_deferrable_unique_constraints via dot notation, but rather by getattr with a default.
This was previously accepted to the original repository in ESSolutions/django-mssql-backend#86. Backwards compatibility for Django < 3.1 is maintained by not directly trying to load the supports_deferrable_unique_constraints via dot notation, but rather by getattr with a default.
This was previously accepted to the original repository in ESSolutions/django-mssql-backend#86. Backwards compatibility for Django < 3.1 is maintained by not directly trying to load the supports_deferrable_unique_constraints via dot notation, but rather by getattr with a default.
This was previously accepted to the original repository in ESSolutions/django-mssql-backend#86. Backwards compatibility for Django < 3.1 is maintained by not directly trying to load the supports_deferrable_unique_constraints via dot notation, but rather by getattr with a default.
|
@svbfromnl https://github.com/microsoft/mssql-django features this fix (just not backwards compatible for < Django 3.1 at the moment); installable via PyPI @ https://pypi.org/project/mssql-django/. I've opened microsoft/mssql-django#9 to re-add support for older Django. |
|
@davidjb Thanks for this fix! However, the current version of |
|
@tlugo-deacero As best I can tell it does (https://github.com/microsoft/mssql-django/blob/dev/mssql/schema.py#L704-L706) -- just that it's not backwards compatible with < Django 3.1. I switched my active project over to using Edit: oh, I see what you mean -- the packaged version doesn't have it. In that case, definitely raise an issue over there to ask Microsoft. Note that I'm not a maintainer of that package, just a contributor -- microsoft/mssql-django#9 (to add Django < 3.1 support as was added here in #86) isn't yet merged so feel free to add a comment or 👍 over there. |
|
This issue is stille happening to me, Im using Django 3.1 |
The last version is from 2016 |
|
@luizfelipevbll Last version of mssql-django is out from 19 Mar 2021 (https://pypi.org/project/mssql-django/#history) - it's being actively worked on and I use it with Django 3.1 at present. |
Shit, I was looking in the wrong pkg django-mssql istead of mssql-django Is mssql-django 1.0b1 stable for production? |
|
@luizfelipevbll Not with that latest packaged version, no -- doesn't support Django 3.2 and has issues with certain DB/ORM operations (in particular you'd be interested in microsoft/mssql-django#9 which re-adds on aspect of Django 3.1 support). The dev version has these fixes, plus those that fix microsoft/mssql-django#25 for Django 3.2 support. I'm not using Django 3.2 at this point, so can't comment more than I've read on the issue tracker. |
This was previously accepted to the original repository in ESSolutions/django-mssql-backend#86. Backwards compatibility for Django < 3.1 is maintained by not directly trying to load the supports_deferrable_unique_constraints via dot notation, but rather by getattr with a default.
Using the current
masterand trying to run migrations on Django 3.1.4 results in the following error:This PR adds the keyword arg to the function definition so it will be accepted. It also adjusts the implementation of this function to match that of the BaseDatabaseSchemaEditor, checking for deferrable support and handling invalid situations. The result is effectively the same, an empty string passed to the
Statement()calls.