On Jun 4, 9:23 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > as long as all tests pass it is fine. If you could give me a patch that > includes a test for this in test_declarative, that would be supremely helpful > (if you want to make a trac ticket and target it at the 0.6.2 milestone).
Will do. > do you mean, if the new class overrides what the mixin provides ? i'm not > sure why we'd need to do anything if the class overrides the mixin. Because the mix-in is itself an API, a public interface defining properties on which other code may depend. It is a superclass, and a subclass should extend or elaborate what the superclass' definition promises — not replace it. That was my thinking. And it was wrong. Because there are further “shouldn't”s: yeah, a subclass shouldn't break its superclass' API, but also a superclass API shouldn't be too specific, and a framework shouldn't be too restrictive. The mix-in specifies the names of its columns, and *maybe* it specifies more detail (e.g. id must be Integer, or name column must be unique), but then that's application-specific. (Sure, that id column has type Integer, but it had to have *some* type; the mix-in author may well mean it as a default and not a restriction.) Allowing whatever property (type, uniqueness) of the columns to be overridden is a valid application design choice, so DeclarativeMeta should not needlessly enforce anything beyond the names. So yeah, you're right, no need to do any more. - Gulli -- 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.