Chris Withers wrote:
> Michael Bayer wrote:
>> Chris Withers wrote:
>>> I see how you've fixed this for 0.6, but it makes me wonder why the
>>> __table_args__ check is there at all? They're essentially benign,
>>> right?
>>> (since in the test case above, it really doesn't make sense for
>>> Specific
>>> to have __table_args__ inside _as_declarative... I can't think of a
>>> test
>>> case where it would be problematic...)
>>
>> there's an assertion for "you specified __table_args__ but no
>> __tablename__", and we check if __table_args__ came from a mixin in
>> which
>> case we don't raise that exception.
>
> I know ;-)
>
> My question was why the assertion needs to be there...
so that people don't say __table_args__ = (UniqueConstraint('foobar')),
expect it to apply to the single table on a superclass, and then complain
on the mailing list that it silently failed.
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@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.
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
