Code

Changes between Version 163 and Version 164 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
06/04/08 17:40:05 (6 years ago)
Author:
jacob
Comment:

Added notes about [7574]

Legend:

Unmodified
Added
Removed
Modified
  • BackwardsIncompatibleChanges

    v163 v164  
    5555 * [7364] March 26, 2008 [#Removedado_mssql Removed ado_mssql] 
    5656 * [7477] April 27, 2008 [#Queryset-refactormerge Queryset-refactor merge] 
     57 * [7574] May 4, 2008 [#TightenedupForeignKeyassignment Tightened up ForeignKey assignment] 
    5758 
    5859== Database constraint names changed == 
     
    591592== Queryset-refactor merge == 
    592593In [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 
     598Specifically, 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).