Fri, 11 Sep 2015 14:28:06 +0200 [py3k] except as
Samuel Trégouët <samuel.tregouet@logilab.fr> [Fri, 11 Sep 2015 14:28:06 +0200] rev 10588
[py3k] except as
Fri, 11 Sep 2015 14:27:34 +0200 [py3k] backtick to repr
Samuel Trégouët <samuel.tregouet@logilab.fr> [Fri, 11 Sep 2015 14:27:34 +0200] rev 10587
[py3k] backtick to repr
Wed, 23 Sep 2015 15:01:55 +0200 [hooks/syncschema] make sure CWUniqueTogetherConstraintDelOp happens before CWConstraintDelOp
Julien Cristau <julien.cristau@logilab.fr> [Wed, 23 Sep 2015 15:01:55 +0200] rev 10586
[hooks/syncschema] make sure CWUniqueTogetherConstraintDelOp happens before CWConstraintDelOp SQLServer refuses to index an unlimited text column, so we should drop unique_together constraints (which imply an index) before we drop size constraints. Closes #5560601.
Wed, 23 Sep 2015 15:00:33 +0200 [hooks/syncschema] only call "ALTER TABLE" once when changing a size constraint
Aurelien Campeas <aurelien.campeas@pythonian.fr> [Wed, 23 Sep 2015 15:00:33 +0200] rev 10585
[hooks/syncschema] only call "ALTER TABLE" once when changing a size constraint Until now we would: - remove the old size constraint from the in-memory schema - call update_rdef_column which removes the size restriction from the column's type - add the new constraint object - call update_rdef_column which adds the size restriction back This breaks on SQL Server when the column is involved in an index (e.g. as part of a multi-column unique constraint), because in the intermediate stage the column's type is "nvarchar(max)", which is not indexable. Of course we must still detect the case where a size constraint is really dropped and update the db schema accordingly. Closes #5557633.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 tip