Re: Why does get_profile exist?

[mrts]

On Apr 15, 11:04 am, David Cramer  wrote:
> I was never a fan of the profile model as it stands. It's not very
> practical in every situation I've ever been in. Being that 1.0 was
> supposed to be backwards compatible, and this is a public API I think
> it needs to stay.
>
> I'd love to see a way to swap out the User model in the future though,
> rather than attach an additional db call for profiles. However, the
> one-to-one approach is a lot nicer than get_profile().

http://code.djangoproject.com/ticket/3011 has a lengthy discussion on
this theme.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[David Cramer]

I was never a fan of the profile model as it stands. It's not very
practical in every situation I've ever been in. Being that 1.0 was
supposed to be backwards compatible, and this is a public API I think
it needs to stay.

I'd love to see a way to swap out the User model in the future though,
rather than attach an additional db call for profiles. However, the
one-to-one approach is a lot nicer than get_profile().

On Apr 13, 11:27 pm, Glenn Maynard  wrote:
> On Tue, Apr 14, 2009 at 12:00 AM, James Bennett  wrote:
> > 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.
>
> Obviously, I didn't say user profiles were narrow; I said the benefit
> of having this special case is limited.
>
> > Second, I'm not sure why you're devoting so much energy to what's
>
> I'm not.  I keep saying it's not a big deal, doesn't really need to be
> changed, and that I just wanted to know how it got that way; you keep
> writing essays in response.  I'm going to elide the rest so I don't
> get another essay dropped on my head.
>
> > 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".
>
> I find the "zero or one to one" case much more commonly useful, and
> OneToOneField is much more natural for that (because ForeignKey's
> reverse gives a set); but that's the subject of another thread (and,
> of course, that topic is what led me to wonder about this one).
>
> --
> 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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[Glenn Maynard]

On Tue, Apr 14, 2009 at 12:00 AM, James Bennett  wrote:
> 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.

Obviously, I didn't say user profiles were narrow; I said the benefit
of having this special case is limited.

> Second, I'm not sure why you're devoting so much energy to what's

I'm not.  I keep saying it's not a big deal, doesn't really need to be
changed, and that I just wanted to know how it got that way; you keep
writing essays in response.  I'm going to elide the rest so I don't
get another essay dropped on my head.

> 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".

I find the "zero or one to one" case much more commonly useful, and
OneToOneField is much more natural for that (because ForeignKey's
reverse gives a set); but that's the subject of another thread (and,
of course, that topic is what led me to wonder about this one).

-- 
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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[James Bennett]

On Mon, Apr 13, 2009 at 8:34 PM, Glenn Maynard  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 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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[Glenn Maynard]

On Mon, Apr 13, 2009 at 8:55 PM, James Bennett  wrote:
> It's true you *might* want to do it for any particular model, but the
> specific case of user profiles is such a common situation that it
> seems a shame to require everybody to come up with their own system
> and their own helpers and such. That's why Django has a standard API
> for handling user profiles.

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, the thing is that Django's had this API for years now, and
> people are familiar with it; while I'm sure it's possible to come up
> with other options which may or may not be "clearer", get_profile()
> has the advantage of already being a known, standard idiom in Django,
> which means people are more likely to recognize it and know what your
> code is doing than if you come up with your own system.

If someone can't instantly understand that "user.profile" refers to
the user's profile, they're already in trouble.  :)

Anyhow, even if it seems like a funny special case to me, it's
probably a total of twenty lines of code in auth, so it's harmless.  I
just wanted to know if there was some deeper design concept behind it.

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

-- 
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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[James Bennett]

On Mon, Apr 13, 2009 at 7:32 PM, Glenn Maynard  wrote:
> Well, you might want to do that for any model, and the admin API
> provides a more generic approach to managing this sort of task--but
> OK.

It's true you *might* want to do it for any particular model, but the
specific case of user profiles is such a common situation that it
seems a shame to require everybody to come up with their own system
and their own helpers and such. That's why Django has a standard API
for handling user profiles.

> It also assumes that there's just one type of profile--I'd think that
> an app that wants to store information per user would want to have its
> own model, since expecting the "main" user of the site to add some
> boilerplate entries to his profile model doesn't seem very nice.  The
> reverse OneToOne mappings mostly scale to this sort of thing cleanly.

It does assume only one profile model, but that's by far the common
case, and so that's what's supported. More complex multi-profile
situations veer off into the realm of things that can't really be
supported by an API that's both simple and generic, and have such
varied use-cases (e.g., how do you decide which type of user gets
which type of profile? Do some users get multiple profiles? Do users
move from one type to another over time?) that asking people to write
their own custom code is more acceptable, since so many of those will
be one-off/highly-specialized systems anyway.

> I don't think "user.get_profile()" is measurably clearer than
> "user.profile", though I guess it would be if you named your profile
> class "Teapot".

Well, the thing is that Django's had this API for years now, and
people are familiar with it; while I'm sure it's possible to come up
with other options which may or may not be "clearer", get_profile()
has the advantage of already being a known, standard idiom in Django,
which means people are more likely to recognize it and know what your
code is doing than if you come up with your own system.


-- 
"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 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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[Glenn Maynard]

On Mon, Apr 13, 2009 at 8:02 PM, James Bennett  wrote:
> user -- they behaved more like normal attributes. At that point
> get_profile() could have been refactored into a read-only property,
> but there really weren't any pressing API-design reasons for doing so.

Sure; that's mostly what I was curious about--whether get_profile() as
an API predated the ORM's current relationship API and was mostly
historical, since it mostly seems like duplicate functionality.

> That means you can write generic code which, for example, looks up the
> profile model and generates a form for it, or which provides generic
> support for managing user profiles (I've written this sort of thing,
> and found it both extremely easy and extremely handy).

Well, you might want to do that for any model, and the admin API
provides a more generic approach to managing this sort of task--but
OK.

It also assumes that there's just one type of profile--I'd think that
an app that wants to store information per user would want to have its
own model, since expecting the "main" user of the site to add some
boilerplate entries to his profile model doesn't seem very nice.  The
reverse OneToOne mappings mostly scale to this sort of thing cleanly.

> Using AUTH_PROFILE_MODULE and get_profile() also helps to clarify to
> other people what your code is doing: by now it's such an established
> convention that people who look at your applications will immediately
> understand what's going on.

I don't think "user.get_profile()" is measurably clearer than
"user.profile", though I guess it would be if you named your profile
class "Teapot".

-- 
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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[Waylan Limberg]

On Mon, Apr 13, 2009 at 4:30 PM, Glenn Maynard  wrote:
>
> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
> declaring the Profile to User relationship as OneToOne and using the
> auto-generated User.profile relationship?
>

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.

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/

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[Glenn Maynard]

On Mon, Apr 13, 2009 at 4:50 PM, Adi Sieker  wrote:
>> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
>> declaring the Profile to User relationship as OneToOne and using the
>> auto-generated User.profile relationship?
>
> Probably because third party apps can then get the user profile and
> don't have to rely on the profile being called profile or whatever.

Third party apps would need columns in it to use it, so apps would
need to require you to manually paste fields into your profile
model--which I assumed wasn't the intent.

> oh, and this list is for the development of django.
> Question about the usage of django should be directed at django-users.

I'm well aware of both lists.  This is a question about the design
(development) rationale of Django.

-- 
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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[Adi Sieker]

Hi,

On 13.04.2009, at 22:30, Glenn Maynard wrote:

>
> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
> declaring the Profile to User relationship as OneToOne and using the
> auto-generated User.profile relationship?
>
> I just changed my Profile's User relationship from ForeignKey to
> OneToOne (the docs say to use ForeignKey, not OneToOne--is this an
> error?) and it works fine.
>
> It does mean you can access the profile without knowing the name of
> the class, but you need to know the contents of the model to do
> anything with it anyway.  Do user profiles predate reverse
> relationships?  I'm just curious about the the design rationale here.
>

oh, and this list is for the development of django.
Question about the usage of django should be directed at django-users.

adi

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Why does get_profile exist?

[Adi Sieker]

On 13.04.2009, at 22:30, Glenn Maynard wrote:

>
> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
> declaring the Profile to User relationship as OneToOne and using the
> auto-generated User.profile relationship?

Probably because third party apps can then get the user profile and
don't have to rely on the profile being called profile or whatever.

adi

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Why does get_profile exist?

[Glenn Maynard]

Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
declaring the Profile to User relationship as OneToOne and using the
auto-generated User.profile relationship?

I just changed my Profile's User relationship from ForeignKey to
OneToOne (the docs say to use ForeignKey, not OneToOne--is this an
error?) and it works fine.

It does mean you can access the profile without knowing the name of
the class, but you need to know the contents of the model to do
anything with it anyway.  Do user profiles predate reverse
relationships?  I'm just curious about the the design rationale here.

-- 
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
-~--~~~~--~~--~--~---