On Monday 13 April 2009 15:28:50 George Vilches wrote:
> On Apr 13, 2009, at 5:55 AM, Shai Berger wrote:
> > 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.
>
> I've been down this road before, and have been shot down with comments
> along the line of "what you really want is a ForeignKey(unique=True,
> null=True)". The problem is that you can't easily follow the reverse
> of that (it requires a separate query, which could get very
> expensive). #7270 attempts to make that case not require an extra
> query for both 121 fields and FK(unique=True), and to have
> FK(unique=True) have an accessor which makes it syntactically similar
> to 121.
This makes little sense to me, as the documentation[1] clearly describes 121
as
similar to a ForeignKey with unique=True, but the "reverse" side of the
relation will directly return a single object.
What you just described is, therefore, a "folding" of 121 into ForeignKey. I
haven't read the patches thoroughly, but in the discussion #7270 says nothing
about syntax changes, just select_related changes, and my concern here is with
logic, not performance.
FWIW, while perusing the ticket, I found Malcolm[2] seeming to agree with my
basic analysis... though perhaps not my conclusions :-)
> The current leaning for that ticket the last time I talked
> with Malcolm is that the 121 portion is very likely to get accepted,
> the FK(unique=True) portion is less likely. However, if you had the
> FK part, would that resolve most of your issues, with the exception of
> the model inheritance instances?
As I said, I don't see syntax changes in #7270, so I'm not sure you're
referring to the right ticket, and I'm not sure what exact set of changes you
are talking about. Also, I don't think I (or anyone on this thread) asked for
syntax changes, but rather for semantic changes (the behavior of the reverse-
relation property).
What I get from your description is a suggestion that:
A) OneToOne reverse relation behavior will not change
B) FK(unique=True) will also create a reverse-relation property returning a
single object, and
C) That reverse-relation property will return None when no object is found, if
the FK is nullable
If that is indeed the suggestion, then I find it lacking for two reasons: It
creates a weird discrepancy between FK and 121, and it doesn't address the
concern that nullability of the reverse relation is independent of nullability
of the primary.
Thanks,
Shai.
[1] http://docs.djangoproject.com/en/dev/ref/models/fields/#onetoonefield
[2] http://code.djangoproject.com/ticket/7270#comment:16
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
