On May 1, 2008, at 11:49 AM, [EMAIL PROTECTED] wrote:
>
>> Now that QSRF has landed, this type of thinking leads me to: who's
>> working on 121-rewrite?
>
> I'm fairly certain that in refactoring QuerySet, OneToOneField has
> been fixed. It's the base mechanism that allows multi-table
>
> Now that QSRF has landed, this type of thinking leads me to: who's
> working on 121-rewrite?
I'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.
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship between users and user profiles is "has-a",
> not "is-a". So what would be
On Apr 25, 2008, at 3:40 PM, Marty Alchin wrote:
> *snip*
> class AuthorProfile(models.Model):
>user = models.OneToOneField(User)
>pen_name = models.CharField(max_length=255)
Now that QSRF has landed, this type of thinking leads me to: who's
working on 121-rewrite? And more
Rajeev,
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
On Mon, Apr 28, 2008 at 3:59 AM, peschler <[EMAIL PROTECTED]> wrote:
>
> On 25 Apr., 21:40, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> >
> > Not to get too much into this discussion, but I tend to be slow to
> > understand design patterns and other paradigms. What then would be the
> >
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:
class Reader(User):
fields...
class Author(User):
fields...
Does this mean that any new instance of
On Fri, Apr 25, 2008 at 3:26 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship
On Fri, Apr 25, 2008 at 1:06 PM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> 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
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.
Rajeev J Sebastion wrote:
> Because every app has its own
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
On Fri, Apr 25, 2008 at 10:23 AM, AmanKow <[EMAIL PROTECTED]> wrote:
> Could you elaborate or point to elaboration on why non-abstract
> inheritance is a bad fit for extending user?
http://www.b-list.org/weblog/2007/feb/20/about-model-subclassing/
--
"Bureaucrat Conrad, you are technically
On Fri, Apr 25, 2008 at 8:53 PM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> > Well, I personally have been saying for over a year that inheritance
> > has never been and never will be the right way to do that, so I think
> > y'all know what my answer is...
>
> Could you elaborate or point to
> Well, I personally have been saying for over a year that inheritance
> has never been and never will be the right way to do that, so I think
> y'all know what my answer is...
Could you elaborate or point to elaboration on why non-abstract
inheritance is a bad fit for extending user?
Thanks!
On Wed, Apr 23, 2008 at 11:16 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> 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
>
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
16 matches
Mail list logo
