|Model Inheritance in qsrf and User?||Rob Hudson||4/23/08 9:16 PM|
I don't know if this should go to devs or users but I wanted to ask...
Now that queryset-refactor has implemented model inheritance (and will
soon be in trunk), will the recommended way to tie in new columns to
contrib.auth.models.User change? For example, if we want to add in
profile information specific to our apps?
|Re: Model Inheritance in qsrf and User?||James Bennett||4/24/08 9:38 AM|
On Wed, Apr 23, 2008 at 11:16 PM, Rob Hudson <trebor...@gmail.com> wrote:
Well, I personally have been saying for over a year that inheritance
|Re: Model Inheritance in qsrf and User?||AmanKow||4/25/08 8:23 AM|
> Well, I personally have been saying for over a year that inheritanceCould you elaborate or point to elaboration on why non-abstract
inheritance is a bad fit for extending user?
|Re: Model Inheritance in qsrf and User?||Rajeev J Sebastian||4/25/08 11:13 AM|
Because every app has its own concept/method of how to link info to a
|Re: Model Inheritance in qsrf and User?||James Bennett||4/25/08 11:26 AM|
On Fri, Apr 25, 2008 at 10:23 AM, AmanKow <wwe...@si.rr.com> wrote:
|Re: Model Inheritance in qsrf and User?||Eric Florenzano||4/25/08 11:39 AM|
The multi-table inheritance stuff in queryset-refactor does
essentially what is mentioned in that article, except it merges the
namespace so that it's easier to use. That being said, it seems that
OneToOneField has been improved as well, for those who want to be
explicit about that link.
On Apr 25, 1:26 pm, "James Bennett" <ubernost...@gmail.com> wrote:
|Re: Model Inheritance in qsrf and User?||AmanKow||4/25/08 12:06 PM|
Hmmm... I read the subclassing post. As a non-abstract child is
essentially a one to one with some syntactical sweetness, I'm still
not sure how using a one to one field is better suited than
inheritance for extending user.
Don't see why each model can't do what they want... one to one,
inheritance, etc to obtain the same result.
Seeking enlightenment as I try to prepare my mind for qsrf
|Re: Model Inheritance in qsrf and User?||Ian Kelly||4/25/08 12:26 PM|
On Fri, Apr 25, 2008 at 1:06 PM, AmanKow <wwe...@si.rr.com> wrote:
Purely in terms of OO design, because it's cleaner. Object
|Re: Model Inheritance in qsrf and User?||Marty Alchin||4/25/08 12:40 PM|
On Fri, Apr 25, 2008 at 3:26 PM, Ian Kelly <ian.g...@gmail.com> wrote:
Not to get too much into this discussion, but I tend to be slow to
Essentially, whether it has the semantics of an "is-a" or a "has-a"
How would I proceed in a situation like this?
|Re: Model Inheritance in qsrf and User?||peschler||4/27/08 3:29 PM|
On 25 Apr., 21:40, "Marty Alchin" <gulop...@gamemusic.org> wrote:I would tend to subclassing in this case. To make my point clear add
another user model called "Reader" to the example:
stories_read = models.IntField()
Assuming that only author's should have a "pen_name" and only readers
should have a "stories_read" field, it would be feeling "not
naturally" to put these fields in a profile (and therefore go the
Furthermore assuming that your site requires *every* user (readers and
authors) to specify their phonenumber (which is not part of standard
User model), this should go into a profile:
user = models.OneToOneField(User)
phone = models.PhoneField()
That way you benefit from both. You have Authors and Readers which are
users ("is-a"), and which both have a phone number ("has-a").
From an OO standpoint you are now able to use Authors and Readers
instances, whereever a User instance is used in the API. This is not
possible when using a profile.
Please be aware that I did not test the qsrf branch and the examples
above and the way I understand things are maybe not how things work.
|Re: Model Inheritance in qsrf and User?||michaelg||4/30/08 10:59 AM|
I just started learning about extending Django's User model, so bear
with me as I make sure I understand these things correctly. So we can
subclass the User class doing something like:
Does this mean that any new instance of Reader or Author will also be
found in User (or some reference to Reader and Author)? I understood
this to be the case based on peschler's UserProfile class:
So this will allow you to create a universal UserProfile class for
Readers and Authors as opposed to doing something like:
user = models.OnetoOneField(Author)
user = models.OnetoOneField(Reader)
Also, what's the difference between OnetoOneField and ForeignKey?
Does it make a difference which one you use? Thanks in advance for
|Re: Model Inheritance in qsrf and User?||rajeev j sebastian (insanekane)||4/30/08 11:17 AM|
On Mon, Apr 28, 2008 at 3:59 AM, peschler <pesc...@googlemail.com> wrote:
The main problem with this approach is multiple apps. For e.g., a site
you get the picture. Thats why User should never be subclassed (for
|Re: Model Inheritance in qsrf and User?||michaelg||4/30/08 11:33 AM|
How, then, would you suggest handling multiple user groups? To
continue with a similar theme from above, let's say we had two user
groups, Authors and Publishers. When signing up, an Author might need
to input their first name, last name, email, and a password, but a
Publisher would only need their publisher name, password, and maybe an
email. We'd have to use a different signup forms to allow for the
differences in first and last name, and publisher name. After
creating an account, an Author might add profile information that is
unique to Authors, and a Publisher might add profile that is unique to
Publishers. Is this still not a candidate for subclassing? Are you
suggesting that all information just be stored in the profile
(including email, password, etc.)? Thanks for helping!
On Apr 30, 11:17 am, "Rajeev J Sebastian" <rajeev.sebast...@gmail.com>
|Re: Model Inheritance in qsrf and User?||George Vilches||4/30/08 11:35 AM|
On Apr 25, 2008, at 3:40 PM, Marty Alchin wrote:
Now that QSRF has landed, this type of thinking leads me to: who's
Things like this would be well served by being able to follow a
I will hesitantly say too, *if* OneToOneFields were to work that way
|Re: Model Inheritance in qsrf and User?||Tai Lee||5/1/08 7:19 AM|
> Purely in terms of OO design, because it's cleaner. ObjectI think whether it is a "has-a" or "is-a" relationship depends on the
developer and the application. There's no reason for a developer not
to extend User and reference their own User model instead of django's,
if it makes more sense to them. Why make Profile models all over the
place when you can just make User models and have all the syntactic
sugar that comes with it, being able to treat it as a single entity?
|Re: Model Inheritance in qsrf and User?||Eric Florenzano||5/1/08 8:49 AM|
> Now that QSRF has landed, this type of thinking leads me to: who'sI'm fairly certain that in refactoring QuerySet, OneToOneField has
been fixed. It's the base mechanism that allows multi-table
subclassing to work, in fact.
|Re: Model Inheritance in qsrf and User?||George Vilches||5/1/08 9:15 AM|
I do not believe you understood what I mean by fixed. OneToOneField
from django.db import models
SELECT `t1_b`.`id`, `t1_b`.`b1`, `t1_b`.`b2_id`, `t1_a`.`id`,
A.objects.select_related() creates this query:
SELECT `t1_a`.`id`, `t1_a`.`a1` FROM `t1_a`
If this worked, then in the User case, you could select_related() on
(As an aside, forward FKs on both sides of the OneToOne should be
Does that make more sense as to why it would alleviate the issue?