users and profiles - model structure question

[andy baxter]

Hello,

I have built a data model for a virtual library, which contains the
following classes (among others):

User - the built in user class from django.contrib.auth.
Member - a profile for each user, containing extra information about
each member.
Item - a book, video, or music album
Iteminstance - a specific copy of an item.

I am thinking about what is the best way to structure this data - in
particular if ForeignKey fields from other tables (like iteminstance)
should refer to the Member table or the User table. At the moment I have
it like this:

Member.user -> User
ItemInstance.owner -> Member
ItemInstance.item -> Item

But I'm not sure about the second of these - should it be
ItemInstance.owner->User?

I'm getting the feeling as I'm starting to write the code dealing with
Members and Users that making the right choice here could be important,
so as not to have to end up writing unnecessarily tangled code as the
model develops in the future (e.g. if I add 'Review' which refers to an
Item and is made by a Member/User).

Has anyone dealt with this problem in practice, and do people have any
thoughts about what is the best way of doing things here, from the point
of view of keeping the code simple, and also minimising the time spent
doing database lookups? (I'm guessing that looking up a User from a
Member is slightly quicker than looking up a Member from a User).

andy

[Alex Koshelev]

I usually make link to User model not profile. And have no problems
with usage.

On Apr 18, 2:02 pm, andy baxter <a...@earthsong.free-online.co.uk>
wrote:

[andy baxter]

Alex Koshelev wrote:
> I usually make link to User model not profile. And have no problems
> with usage.
>
>

I just tried switching to this way of doing it, and have come up against
a problem with getting the profile data into the template. If I create a
list of all users in the view, then pass the list of users to the
template as user_list, I would like to be able to iterate over the list
using '{% for user in user_list %}', and then retrieve the data from the
profile inside the template. I tried doing {{
user.get_profile.self_description }}, which is meant to retrieve the
self_description field from the Member object associated with the given
User. But this raises a template error: 'Too many values to unpack'

Is it possible to refer to profile data in the template like this, or do
I need to find another way to do it?

andy

[andy baxter]

Sorry, forget that - I just had AUTH_PROFILE_MODULE set wrong. Now it's
working OK.

andy.

[Malcolm Tredinnick]

On Fri, 2008-04-18 at 11:02 +0100, andy baxter wrote:
[...]

> Has anyone dealt with this problem in practice, and do people have any
> thoughts about what is the best way of doing things here, from the point
> of view of keeping the code simple, and also minimising the time spent
> doing database lookups? (I'm guessing that looking up a User from a
> Member is slightly quicker than looking up a Member from a User).

This is kind of an interesting problem and I've come across it twice
recently and ended up going with different approaches each time.

Firstly, to get rid of one source of confusion, there is no difference
traversing from User -> a profile or vice-versa. Both require a table
join at the database level. If you're splitting hairs on the difference
at the Python code level, it's so minor (and so varied) that something
is seriously wrong if you notice it. So that (direction) should not be a
consideration at all.

In both my cases, I originally tried to puzzle out what would be the
"obvious, right" way, but it only became clearer after I started writing
code. In one case, most of the uses of the User+Profile pair was dealing
with aspects of the standard user model (auth stuff, permissions and
things like that), so I mostly needed to access User. In the other case,
I was mostly referring to the profile object and so the many, many
models I have linking back to the "user" link to this profile: because I
primarily need the extra information.

I'm still not sure I could have completely puzzled this out in advance,
without more or less writing the code in my head. That's kind of the
cost (and benefit) of rapid development: you can happily try something
out and change a little later. On the first project (where I end up
pointing to User), it became clear fairly quickly that the User model
was the right one. In the second case, I vacillated a fair bit and
changed my mind more than once over a three or four day period. The fact
that it was such a line ball also convinced me it probably wasn't that
big a deal. My time budget isn't being predominantly spent on the
User/Profile joins and lookups, it's going elsewhere. So it probably
wouldn't have mattered much and at some point I made a conscious
decision to stop worrying about that and move on. It was starting to
dominate my thinking a bit too much.

Regards,
Malcolm

--
I intend to live forever - so far so good.
http://www.pointy-stick.com/blog/