It would be great for declarative to resolve a conflict (perhaps with
a warning) if the column definitions are exactly the same - though I
can see this getting complicated with nested ForeignKey objects, etc.
That said, I really like the idea of exposing the conflict resolution
mechanism to the user. Perhaps, it could even be made simpler by
adding a kwarg to the Column definition:
class MyMixin(object):
@declared_attr
def target_id(cls):
return Column(Integer, ForeignKey('target.id'),
replace_existing=True)
On Apr 18, 7:11 am, Michael Bayer <[email protected]> wrote:
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
