On Mon, Apr 13, 2009 at 6:01 PM, Waylan Limberg <[email protected]> wrote: > Well, prior to qs-refactor (just before 1.0), OneToOnes had some > issues and the documentation included very strong warnings that they > should not be used at all. That being the case, as that time you found > almost no use of OneToOne relationships within the community, let > alone Django itself. So, at least in part, the answer is for > historical reasons.
I still see some issues with OneToOne reverse relationships. In particular, it's easy to accidentally assign to them, which doesn't work as one would expect--you have to save the model that holds the relationship to save the change, so this leads to silent faliures: obj.related = obj2 obj.save() # should be obj2.save() obj.related = obj3 obj.save() # should be obj2.save(); obj3.save() in that order obj.related = None obj.save() # should be obj3.save() I assume these are known limitations that are probably a bag of worms to fix, but the main issue I have is that it leads to obscure failures: these reverse relationships look the same as a forward relationship, so I need to carefully examine the object to see if "related" is a forward or reverse relationship whenever I assign to it. It would be useful if I could specify that I never want to be assign to a reverse relationship and an exception should be thrown--any time I'm doing that, it's probably a mistake. > See other reasons discussed elsewhere [1]. Particularly the last > section of that post. > > [1]: > http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/ > It’s a completely consistent generic interface. Using the standard API in the > example above means hard-coding u.userprofile all over the place; what > happens if you later change the name of that model, or decide you need to > reuse that code somewhere else? Using the AUTH_PROFILE_MODULE setting and > get_profile() makes your code more robust and more portable. The same argument could be made for every relationship, both forward and backward, and the result would be wrapping every relationship in a function. > It makes site-specific user customization insanely easy. If you’re using > Django’s bundled ‘sites’ application to manage multiple sites which each have > their own settings files, each one can use a different custom model tailored > to its needs. If they're different models, then they presumably contain different things. I don't know what the benefit is of having a consistent method name to access inconsistent models. Anyhow, I'm not advocating changing it--nothing prevents people from ignoring get_profile entirely and just using OneToOne (which is probably what I'll do). -- 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 [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 -~----------~----~----~----~------~----~------~--~---
