Changes between Version 163 and Version 164 of BackwardsIncompatibleChanges
- Timestamp:
- Jun 4, 2008, 7:40:05 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BackwardsIncompatibleChanges
v163 v164 55 55 * [7364] March 26, 2008 [#Removedado_mssql Removed ado_mssql] 56 56 * [7477] April 27, 2008 [#Queryset-refactormerge Queryset-refactor merge] 57 * [7574] May 4, 2008 [#TightenedupForeignKeyassignment Tightened up ForeignKey assignment] 57 58 58 59 == Database constraint names changed == … … 591 592 == Queryset-refactor merge == 592 593 In [7477] the [QuerysetRefactorBranch queryset-refactor branch] was merged into trunk. This is mostly backwards compatible, but there are a few points to note. Rather than list them here, refer to the [QuerysetRefactorBranch#Backwardsincompatiblechanges backwards incompatible changes] section on the branch's wiki page. 594 595 == Tightened up !ForeignKey assignment == 596 [7574] tightened up restrictions on assigning objects to {{{ForeignKey}}} and {{{OneToOne}}} fields (i.e. assignments of the form {{{book.author = someinstance}}}). 597 598 Specifically, Django will now: 599 600 * Raise a {{{ValueError}}} if you try to assign the wrong type of object. Previously things like {{{book.author = Vegetable(...)}}} worked, which was insane. 601 * Raise a {{{ValueError}}} if you try to assign {{{None}}} to a field not specified with {{{null=True}}}. 602 * Cache the set value at set time instead of just at lookup time. This avoids race conditions when saving related objects along with their parents and was the original impetus for the change (see #6886).