You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Only drop necessary indexes during field rename (#97)
* Only drop unique indexes which include the column to be renamed
This avoids unnecessarily slowing down migrations with
drop/recreate of index(es) on potentially large tables
when doing so is not required.
* Test for rename of unique-and-nullable column
This covers the specific case where we are still
dropping a unique index on a column & re-instating.
Also update references to an issue which was ported
to the new fork and fixed there (here).
* Add general test for presence of indexes
This is not a panacea but hopefully increase the coverage
if nothing else by at least being a regression test for
#77
* Basic logging config for debugging testapp tests
* Fix KeyTransformExact applied to all databases (#98)
* Fixed issue #82
* Issue #90 - fix alter nullability for foreign key (#93)
* Issue #90 bug fix
* Update SUPPORT.md (#101)
Remove paragraph pointing users to a the Django mailing list.
[skip ci]
* Add possibility for token authentication (#102)
* Add possibility for token authentication
* Add documentation for TOKEN setting
* Fixed overridden functions not working with other DBs (#105)
Fixes issue #92 and other potential issues caused by overriding Django functions in functions.py.
* Remove unique constraints (fixes#100 and #104) (#106)
* Add support for unique_constraint to introspection, and use it to determine if we should use DROP CONSTRAINT or DROP INDEX when altering or removing a unique (together) constraint. Fixes#100 and #104.
In the sys.indexes table, is_unique_constraint is true only when an actual constraint was created (using ALTER TABLE ... ADD CONSTRAINT ... UNIQUE).
Because this method is not suitable for nullable fields in practice (you cannot have more than one row with NULL), mssql-django always creates CREATE UNIQUE INDEX instead.
django-pyodbc-azure behaved differently and used a unique constraint whenever possible.
The problem that arises is that mssql-django assumes that an index is used to enforce all unique constraints, and always uses DROP INDEX to remove it.
When migrating a codebase from django-pyodbc-azure to mssql-django, this fails because the database contains actual unique constraints that need to be dropped using "ALTER TABLE ... DROP CONSTRAINT ...".
This commit adds support for is_unique_constraint to the introspection, so we can determine if the constraint is enforced by an actual SQL Server constraint or by a unique index.
Additionally, places that delete unique constraints have been refactored to use a common function that uses introspection to determine the proper method of deletion.
* Also treat primary keys as constraints instead of as indexes.
Co-authored-by: Ruben De Visscher <[email protected]>
* Returning ids/rows after bulk insert (#107)
* Implement can_return_rows_from_bulk_insert feature, returning ids or rows after bulk inserts.
* Since mssql-django supports Django 2.2, we also need the pre-Django 3.0 version of feature flag can_return_rows_from_bulk_insert (namely, can_return_ids_from_bulk_insert) (cf. https://docs.djangoproject.com/en/4.0/releases/3.0/#database-backend-api)
* My alternative changes on SQLInsertCompiler.as_sql.
Maybe a bit ambitious, as we completely forsake the SCOPE_IDENTITY strategy (dead code path - we keep the code here, but we could decide not to, really) in favor of OUTPUT strategy.
* Don't try to use the OUTPUT clause when inserting without fields
* Actually we don't really have to offer the feature for Django 2.2, so let's only set can_return_rows_from_bulk_insert to True and not can_return_ids_from_bulk_insert
* Tentative fix: when there are returning fields, but no fields (which means default values insertion - for n objects of course!), we must still fulfill our contract, and return the appropriate rows.
This means we won't use INSERT INTO (...) DEFAULT VALUES n times, but a single INSERT INTO (...) VALUES (DEFAULT, (...), DEFAULT), (...), (DEFAULT, (...), DEFAULT)
Also: be more thorough re the infamous feature flag rename from Django 3.0
* Using MERGE INTO to support Bulk Insertion of multiple rows into a table with only an IDENTITY column.
* Add a link to a reference web page.
* Attempt to make Django 2.2 tests pass
* Get back to a lighter diff of as_sql function vs. original
* Use a query to generate sequence of numbers instead of using the master....spt_values table.
* Update mssql/operations.py
Co-authored-by: marcperrinoptel <[email protected]>
* Simplification & refactoring
Co-authored-by: marcperrinoptel <[email protected]>
Co-authored-by: marcperrinoptel <[email protected]>
* The reset_sequences argument in sql_flush must be understood as relative to the tables passed, not absolute. (#112)
The present fix aligns the relevant code snippet with the one from the closest impl. i.e. Oracle - cf. https://github.com/django/django/blob/795da6306a048b18c0158496b0d49e8e4f197a32/django/db/backends/oracle/operations.py#L493
* Adds unit test for issues #110 and #90 (#115)
* Added test to test changing from non-nullable to nullable with unique
index
* Fixed failing unit test on Django 3.1 and lower due to bad import
* Unskip one passed test (#116)
Unit test `bulk_create.tests.BulkCreateTests.test_bulk_insert_nullable_fields` is passing, remove it from expected failures.
* Add offset clause for all Django versions (#117)
Issue #109, missing OFFSET clause causes select_for_update() to fail
* Create devskim.yml (#120)
* Fixed missing ValidatorError import (#121)
* Updated supported Django versions (#122)
* Bump up version to 1.1.3 (#123)
Co-authored-by: Tom Sparrow <[email protected]>
Co-authored-by: jmah8 <[email protected]>
Co-authored-by: jean-frenette-optel <[email protected]>
Co-authored-by: Anthony Shaw <[email protected]>
Co-authored-by: Petter Moe Kvalvaag <[email protected]>
Co-authored-by: Ruben De Visscher <[email protected]>
Co-authored-by: Ruben De Visscher <[email protected]>
Co-authored-by: marcperrinoptel <[email protected]>
Co-authored-by: marcperrinoptel <[email protected]>
Copy file name to clipboardExpand all lines: SUPPORT.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,8 +6,6 @@ This project uses GitHub Issues to track bugs and feature requests. Please searc
6
6
issues before filing new issues to avoid duplicates. For new issues, file your bug or
7
7
feature request as a new Issue.
8
8
9
-
For help and questions about using this project, please utilize the Django Developers form at https://groups.google.com/g/django-developers. Please search for an existing discussion on your topic before adding a new conversation. For new conversations, include "MSSQL" in a descriptive subject.
10
-
11
9
## Microsoft Support Policy
12
10
13
11
Support for this project is limited to the resources listed above.
0 commit comments