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. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@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.
