On Apr 17, 2012, at 8:23 PM, Amos wrote:
> Thanks for the clarification. I did play around with __abstract__ but
> like you said it doesn't work in the middle of the inheritance chain.
> The main idea behind this approach is the DRY concept - define the
> columns/relationships only once and use them interchangeably in any of
> the derived STI models. This workaround sort of accomplishes that but
> at the same time restricts you to a hierarchical model, whereas using
> mixins is much more flexible.
the issue with mixins here is that you essentially have two mixins saying
something that conflicts, they both create a Column object with the same name.
One could have a different "info" dict than the other, for example - it would
be a surprise for declarative to just pick one, and discard the other. For
declarative to compare them is also something I'd rather not get into as again
things like the "info" dict and custom subclasses of Column couldn't
necessarily be compared.
But I thought of a possible way to give this capability to you, a new method
__conflicts__, like this:
class MyMixin(object):
@declared_attr
def target_id(cls):
return Column(Integer, ForeignKey('target.id'))
@classmethod
def __conflicts__(cls, key, existing, new):
if key == 'target_id':
return existing
else:
return None
so basically, instead of declarative raising "column x conflicts with existing"
it will first call __conflicts__ on your class (which could be anywhere in the
hierarchy), giving your code a chance to resolve.
What I like about this is that declarative's behavioral contract doesn't change
at all for anybody, it doesn't have to get into comparing or silent guessing,
and the feature itself, which would be very rarely used as this is not a
typical use case, would have a decent place for documenting under the "special
methods" section of declarative and also be a very simple, two line feature.
--
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.
