#11811: No error raised on update(foreignkey=unsavedobject) on nullable fk
---------------------------------------------------+------------------------
          Reporter:  Afief                         |         Owner:  ashearer
            Status:  assigned                      |     Milestone:  1.2     
         Component:  Database layer (models, ORM)  |       Version:  1.1     
        Resolution:                                |      Keywords:          
             Stage:  Accepted                      |     Has_patch:  0       
        Needs_docs:  0                             |   Needs_tests:  0       
Needs_better_patch:  0                             |  
---------------------------------------------------+------------------------
Comment (by ashearer):

 The same surprising behavior occurs whether you assign to the ForeignKey
 field by attribute assignment, a model initializer,
 model.objects.create(), or queryset.update(). In any of the cases, passing
 an unsaved model acts the same as passing None. (That's assuming no manual
 pk assignment.) The first three use a different code path than the last.

 I'm attaching a strawman patch that will raise a ValueError with a helpful
 message in all four cases. The docs had left the behavior undefined.

 However, the patch needs further work:
  1. Raising an exception at assignment time may be a bad idea, even though
 the inconsistency between my_fk_field (an object) and my_fk_field_id
 (None) starts then. Everything would have worked OK while the same object
 remained in memory; only the copy saved in the DB will have no link at all
 to the other instance. Checking at save time may be better.
  2. To match the scope of the ticket, I'm only handling assignment for
 non-null fields. Non-nullable fields already raise an exception, though it
 occurs later (on save), and the error message is less specific as a
 result. But the queryset.update() code path now always throws the new
 exception regardless of whether the field is nullable, because field
 information isn't available to it.
  3. Two tests of multi-DB support now fail, because they make the same
 mistake the new exception is designed to guard against. Either putting
 explicit IDs in the tests or changing the timing of the exceptions as per
 point 1 may help. The rest of the test suite has no additional failures.

 The patch includes tests but not docs. I'll attach a docs patch separately
 once the implementation settles down.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/11811#comment:3>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to