there's other edges too, like a custom Column subclass, and contents within the
open-ended info dict, so __conflicts__ keeps this simple.
I've added ticket 2472 for this.
On Apr 19, 2012, at 4:31 PM, Amos wrote:
> 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.
>
--
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.
