On Mon, Apr 13, 2009 at 9:26 AM, Shai Berger <s...@platonix.com> wrote: > 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.
I agree; I only suggested the method I did for backwards compatibility. If you can convince people that the migration is worth it, then one migration path would be to do what I said, and then change the default to reverse_null=True for 2.0. I think the exception behavior should stay available, though, since sometimes that is what you want, and it's a nasty migration path to fully eliminate it: you'd have to audit your entire codebase to check everywhere that depends on the exception being raised for error handling, which means every place these reverse relationships are accessed at all. That's far worse than just editing all of your OneToOne declarations. On Mon, Apr 13, 2009 at 9:26 AM, Shai Berger <s...@platonix.com> wrote: > On Monday 13 April 2009 15:28:50 George Vilches wrote: > 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 Other than C, I guess one way of looking at this is: - OneToOne *really* means exactly one to one: each object on both sides of the relationship has exactly one on the other side. In this case, raising an exception is correct, but as you said, this is a relatively rare case, and the documentation should even say "OneToOne is probably not what you want". - ForeignKey means OneToZeroOrOne (perhaps "ZeroOrOneToOne" is more accurate) if unique=True. This seems a little odd: the uncommon OneToOne case gets its own relationship class, and the very common case gets tucked away in a flag. I'd suggest the "one to one (or none)" relationship type should have its own type, for the same reason OneToOne exists--it's a distinct type of relationship. I don't know what it would be called, though; "OneToZeroOrOne" is awkward. I don't think this wins anything over a flag in OneToOne, though, other than an awkward class name. -- Glenn Maynard --~--~---------~--~----~------------~-------~--~----~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
