Thanks again for your feedback on this Malcolm, I've created the
following ticket in Trac:
Proxy models: subclass a model without creating a new table
http://code.djangoproject.com/ticket/10356
Cheers,
Ryan
--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed
On Wed, 2009-02-25 at 16:06 +1100, Ryan Kelly wrote:
[...]
> > The use-case for the pure-Python inheritance that has been floating
> > around is the case when you want to, say, use a different User manager
> > in your own views. You don't want to change the auth app's behaviour in,
> > say, admin,
> Oh, okay. Yeah, that's quite different. I'm not convinced that should go
> into Django. Again, there's a consistency thing: we present the object /
> class type that is asked for, not some transparently descended version.
I think my explanation may have been a bit off...
> The use-case for the
On Wed, 2009-02-25 at 15:12 +1100, Ryan Kelly wrote:
> > > If I'm feeling inspired tomorrow, I might try to formulate similar logic
> > > as a patch to the ModelBase metaclass, so that subclasses that don't add
> > > any fields will get pure-python inheritance by default.
> >
> > That (changing t
> > If I'm feeling inspired tomorrow, I might try to formulate similar logic
> > as a patch to the ModelBase metaclass, so that subclasses that don't add
> > any fields will get pure-python inheritance by default.
>
> That (changing the default behaviour) would be a bad idea. The
> implicit prima
On Tue, 2009-02-24 at 22:38 +1100, Ryan Kelly wrote:
> > > is there a way to have a model subclass avoid the creation of a
> > > new database table,and just take its data straight out of the table for
> > > its superclass?
> >
> > Right now, I suspect you would also have to manually set Meta.db
> > is there a way to have a model subclass avoid the creation of a
> > new database table,and just take its data straight out of the table for
> > its superclass?
>
> Right now, I suspect you would also have to manually set Meta.db_table
> and some things like that. However, I strongly suspect
> There's a ticket open in Trac (my internet connection is terrible at the
> moment, so I'm not going to hunt it out) that is to add an option to the
> Meta class saying "this model is not to be managed by Django".
Thanks Malcolm, I'll definitely take a look and see if I can help out on
the ticket
On Mon, 2009-02-23 at 17:11 +1100, Malcolm Tredinnick wrote:
[...]
> There's a ticket open in Trac (my internet connection is terrible at the
> moment, so I'm not going to hunt it out) that is to add an option to the
> Meta class saying "this model is not to be managed by Django".
> Primarily, tha
On Mon, 2009-02-23 at 16:54 +1100, Ryan Kelly wrote:
> Hi All,
>
>
> I'm currently working on an authentication backend that adds some
> functionality to the standard one, and as part of this I want to modify
> the behaviour of the User class. I've been subclassing auth.models.User
> using st
Hi All,
I'm currently working on an authentication backend that adds some
functionality to the standard one, and as part of this I want to modify
the behaviour of the User class. I've been subclassing auth.models.User
using standard model inheritance and it seems to be working fine.
Howeve
11 matches
Mail list logo
