On Mon, Apr 13, 2009 at 8:34 PM, Glenn Maynard <[email protected]> wrote:
> You don't need to come up with helpers--OneToOneField automatically
> creates the only helper this provides, in a way that (unlike
> get_profile()) is consistent with all other model relationships. It's
> standardizing how to get to something while leaving that something
> completely undefined, so you can't actually do much of anything with
> it except stuff like auto-generated forms. It just seems like a
> narrowly useful special case.
Well, first of all user profiles aren't a "narrowly useful special
case" -- they're an extremely common feature needed on lots of
real-world sites. So having some sort of standard API for that is a
good thing.
Second, I'm not sure why you're devoting so much energy to what's
basically a bikeshed argument (we painted it "get_profile()", and you
want it to be painted "profile"). Yes, it's named that way for largely
historical reasons, but to change it at this point, given our
compatibility policy, we'd need conclusive proof that it's completely
broken. Which it isn't: it works just fine, you just happen to not
like the name.
Third, as I've pointed out, basing it off AUTH_PROFILE_MODULE makes
things like determining the profile model a bit easier (to get at it
from nothing but a related name, you need to know enough undocumented
stuff to walk your way across a couple of internal-only objects).
It also avoids any confusion that might come from someone sticking an
attribute of the wrong name onto a User ('profile' can and probably
does mean "related object storing user-specific profile information",
but it doesn't necessarily mean that, and having people think you're
implementing an interface when you're not is risky), and makes it a
bit easier to work around potential namespace collisions (what happens
if you're using two apps, each of which has a model that can be used
as the profile? Under a magical-reverse-name scheme one or the other
would blow up with an accessor collision, but with AUTH_PROFILE_MODULE
you don't get forced into naming the relation a particular way and so
can avoid this problem).
> Also, it's not mutually exclusive with accessing the profile
> directly--is there any reason the docs shouldn't recommend
> OneToOneField instead of ForeignKey for the profile's user field?
> It's a better fit; this seems like a relic from before OneToOneField
> was stable.
> http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users
Personally I'm still a bit wary of OneToOneField. Not for any reason
related to the code or technical issues, but simply because of what it
implies -- OneToOneField is most useful for handling the link between
two classes in a multi-table inheritance situation (which is how
Django makes use of it internally), and any time I see a OneToOneField
my instinctive reaction is "oh, this is meant to behave like a
subclass of that other model".
A unique ForeignKey, on the other hand, doesn't carry any such semantics.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
