On Saturday 23 Jul 2011 8:24:31 PM Michael Bayer wrote: > On Jul 23, 2011, at 7:54 AM, Fayaz Yusuf Khan wrote: > >> When C inherits from CMixin and Timeline, Python's method resolution is > >> going to put TMixin after Timeline, that is: > >> > >> (<class '__main__.C'>, <class '__main__.CMixin'>, <class > >> '__main__.Timeline'>, <class '__main__.TMixin'>, <class > >> 'sqlalchemy.ext.declarative.Base'>, <class '__main__.TableName'>, <type > >> 'object'>) > > > > Maybe, joint-table inheritance and mixin syntaxes should be made more > > distinct and unambiguous? > > It may well be impossible (and backward incompatible) to implement in the > > current code-base, but a usage recipe which implements this behaviour > > might be possible. > > In my view this is the expected behavior of Python's class resolution. > Declarative builds on top of this concept to produce mappings based > polymorphic class behavior, which means the most class-specific attribute > wins. > > If an attribute named X is a mapped column by the mapped parent, and that > is the first __mro__ that the child class can see it, it follows that the > child class should not have this column copied out to its own table unless > the child specifies this attribute in some other way as to override it - > else joined inheritance would not be possible to set up with > @declared_attr, every @declared_attr would be copied out to all > subclasses. > > It's easy to produce tests where the "wrong" behavior occurs, if I force > declarative to hit the @declared_attr directly (I added some in the > changeset I implemented regarding this). > > Perhaps a flag on @declared_attr, something like > @declared_attr(final=True), meaning, use this @declared_attr directly in > all cases regardless of what the class actually sees. That seems a > little hard to explain. I think you should consider as I mentioned that > your subclass columns and superclass columns of the same name aren't > really "the same", and just use different mixins for those two roles.
The problem with using different mixins is that you lose out on a lot of code
reusability. In my case, I have a 'user' column that appears in almost all
table declarations. To have a separate mixin class for each joint-table
inheritance would destroy the purpose of having a mixin altogether.
Now, I'm thinking that messing with the mro may not be a good solution after
all. Having a "final" argument for declared_attr seems unintuitive.
Perhaps, there should be a shorthand for implicitly creating columns along
with foreign key constraints?
So something like
ImplicitForeignKeyConstraint(
['user', 'timestamp'],
['Timeline.user', 'Timeline.timestamp'], primary_key=True)
should lead to the creation of
Column('user', String, primary_key=True),
Column('timestamp',Integer, autoincrement=False, primary_key=True),
ForeignKeyConstraint(
['user', 'timestamp'],
['Timeline.user', 'Timeline.timestamp'])
ie., the column definitions should be fetched from the refcolumns.
But I think some flags should be settable from this side too. Not sure about
how flexible that can be made.
--
Fayaz Yusuf Khan
Cloud developer and designer
Dexetra SS, Kochi, India
fayaz.yusuf.khan_AT_gmail_DOT_com
fayaz_AT_dexetra_DOT_com
+91-9746-830-823
signature.asc
Description: This is a digitally signed message part.
