Michael Bayer wrote:
Suppose you had a joined table setup, and you placed a Constraint in the
__table_args__ of the base class. You certainly don't want that feeding
into the table of the subclass. So like the case with __mapper_args__,
unconditional inheritance of the attribute is a bad idea.
Because SA has chosen to model table inheritence with python
inheritance, I'd agree. However, when __mixin__ has been specified on a
class, it should be treated as just that; a mixin, that behaves exactly
like any normal python class, inheriting everything from its bases, etc...
As an aside, for me it's a shame that declarative chose to model table
inheritance with python inheritance. I think it's confusing that, when
using declarative, inheritance suddenly behaves differently than it does
in any other use of python. I think it's also a shame that you end up
having to do metaclass programming just to get what is, everywhere else,
a normal feature of python. For me, it would have been better to have a
special attribute to say "this inheritance is table inheritance" rather
than having to do that just to say "please make this class behave like a
normal python class"...
So again, and at this point you should just consider this research towards
an actual feature being added to SQLAlchemy, you need to roll this into
the DeclarativeMixin recipe at
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/DeclarativeMixins .
If/when we add this to SQLA, it will be : any class that has
__declarative_mixin__ = True on it will be used to propagate everything to
subclasses. you can of course stick that on the base you send to
declarative_base() too for the same effect.
What's not yet clear - should this mixin affect an existing
__mapper_args__ or __table_args__ on the subclass, i.e. add its own values
into the collections ? At the moment I think it should do it for all the
keyword arguments.
Why make work here? Just let these behave as normal python classes would
treat them...
class A:
something = {'foo':1}
class B(A):
something = {'bazz':2}
A python programmer would expect B's something to be {'bazz':2} not
{'foo':1,'bazz':2}.
If they wanted that, they'd do:
# this should be in the python core :-S
class classproperty(property):
def __get__(desc, self, cls):
return desc.fget(cls)
from unittest import TestCase
class Tests(TestCase):
def test_class_property(self):
class A(object):
something = {'foo':1}
class B(A):
@classproperty
def something(cls):
d = dict(super(B,cls).something)
d.update({'bazz':2})
return d
self.assertEqual(B.something,{
'foo':1,
'bazz':2,
})
cheers,
Chris
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
