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.
