> > 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 primary key field shouldn't just magically not appear because > something else isn't there.
Indeed - and on further reflection it seems that what I want is a little
different from normal subclassing anyway. Standard subclasses require
only that all instances of the subclass are also instances of the base
class. In this case, I'm trying to make all instances of the base class
automatically be available as instances of the subclass.
I wonder if there's a standard terminology for this - I'm calling them
"virtual subclasses" but maybe they should be called "facade subclasses"
or something like that?
> The good news, though, is that I suspect a patch to ModelBase will be
> a bit simpler than your decorator, since we can just conditionally
> check _meta.managed to determine whether to add things like the
> auto-fields and the links back to the parent.
Yep, getting a patch working for this was pretty straightforward.
However, I think it would be better to use a distinct option instead of
overloading "managed", since it would be quite legitimate for someone to
want an unmanaged subclass that still lived in its own (manually
created) database table.
My current patch uses "virtual", so I can do the following:
def MyUser(auth.models.User):
class Meta:
virtual = True
def an_extra_method(self):
print "hooray!"
What do you think? I intend to pretty this up and submit a patch
sometime this evening.
Cheers,
Ryan
--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
r...@rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details
signature.asc
Description: This is a digitally signed message part
