A word of warning for the reading committer who's busy with 1.1 issues: The following contains backwards-incompatible change suggestions, and so should probably be left to later.
On Monday 13 April 2009 08:53:30 Elliott wrote: > On Apr 12, 1:51 am, Glenn Maynard <[email protected]> wrote: > > Accessing a reverse OneToOneField mapping with no object raises > > DoesNotExist (http://code.djangoproject.com/ticket/10227). I think > > the difference between when an object is expected and when None is an > > ordinary result is strong and common enough to warrant a field option. > > > > The vast majority of the time, I want None on a reverse OneToOne > > mapping, and having to catch DoesNotExist every time is a pain. I think a stronger case can be made: The reverse OneToOne relation just should not throw DoesNotExist, always returning None when there is no matching object. This is a realization of the idea that "OneToOne" relations are really, in a total majority of cases, "OneToZeroOrOne" relations. To support this claim, think of the most common use for OneToOne relations: multi-table inheritance. In this case, the claim "the reverse relation should always find an object" translates to "every parent instance should also be an instance of _every_ child", which I find nonsensical. (well, yes, the above is taking it a bit far. what it minimally translates to is "you should never access the child through the parent without prior evidence that the parent is actually a child instance". This interpretation still makes things much more cumbersome than they need to be, suggesting type- fields on parents and similarly horrible kludges). > > Occasionally, I want to assume that the object will always exist and > > raising an exception if it doesn't is correct. > > contrib.auth.User.get_profile() is an example of a usage that probably > > actually would want an exception, if it had been implemented with > > reverse mappings. This is a very specific use-case; a hook for extension by inheritance. As get_profile demonstrates, it is probably better to use more specific mechanisms in such cases anyway. Using reverse-relations with such hooks implies all sorts of limitations on the extending code. As mentioned above, I realize what I'm advocating here is a backwards- incompatible change; what I hope to achieve is agreement that this should be the correct behavior, and then a migration path towards it. My 2 cents, Shai. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
