On Sat, May 31, 2008 at 9:25 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Hi folks -- > > I'm being bitten by http://code.djangoproject.com/ticket/6886. Short > version: ``object.related = obj`` doesn't stick the assigned object in > the model cache (the same way accessing ``object.related`` does) and > can lead to weird mis-matches between modified objects and ones fresh > from the db. > > I've attached a fix to that ticket -- it's a very simple patch -- but > I'm not sure why were weren't simply doing this in the first case, and > I'm a bit concerned that there's a good reason...
SVN knows all: http://code.djangoproject.com/changeset/2598 The checkin message is slightly misleading - the code duplication identified by the checkin message isn't a significant problem in this case, it's the need to validate the cache before it is populated. > Can someone with some familiarity with related fields take a look at > this and reassure me that I'm not doing something stupid here? The edge case to look at is assigning None to the a foreign key where null=False. >>> book.author = None >>> print book.author As the code currently stands, the second line will throw a DoesNotExist exception. If you apply the patch (or revert 2598, however you want to look at it), the None is dutifully returned - you don't get the exception because the invalid value has been forced into the cache. Looking more broadly, a similar problem exists if you were to assign a non-Author object. However, the currently deployed code doesn't handle this case in a particularly elegant fashion: you're guaranteed to get back either an object or an exception, but the object might not be particularly meaningful. This suggests to me that the current code could do with some validation improvements. Ticket #6886 poses a problem. I can see that having to refetch from the database is inefficient, and I can see how race conditions could emerge. The change you are proposing would work if you expanded it to bring the validation check into the __set__ method, but it would have the side effect of introducing field validation at time of assignment. This would make ForeignKeys inconsistent with other attribute assignments. That said, I could probably live with this inconsistency. Foreign keys are already slightly special cases; I don't see any particular harm in making them a little more special. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
