Michael Bayer wrote:
We can fine tune the restriction to be more about specifically what was in that
ticket, i.e.
BaseClass(Base)
some column
Mixin
some column with foreign key to BaseClass.some column
ActualClass(BaseClass)
some column that overrides BaseClass.some column
For the record, this isn't the case in the ticket issue, in the ticket
issue, the mixin just has a foreign key to another table, so I really
can't see any problem with it.
issue #1. BaseClass.some column never gets bound to a table (its copied).
Sure it does, since both ActualClass and BaseClass are mapped classes,
I'd expect BaseClass to map it and some kind of table inheritence to be
in effect in ActualClass. That said, I'm not knowledgeable about what
happens in your example, even if mixins are taken out of the equation
(the mixin isn't actually used in your example, was that intentional?)
issue #2. Mixin.some column also never gets bound to a table (its copied).
Well, this is true since Mixin is never used, I wouldn't expect that to
be true otherwise...
it has a foreign key pointing to another non-used column. Confusing error
messages ensue.
Why are the error messages confusing? What happens in a non-declarative
situation when you have a foreign key referencing a Column that isn't in
a Table? (again, I'm at a disadvantage here, since I've never used SA
non-declaratively...)
issue #3. ActualClass overides BaseClass.some column completely.
Right, in this case, I'd expect barfage, until someone volunteers the
time/tests to make it otherwise...
Even if the copies could figure out who they really need to point to in #1 and #2, they're *still* wrong - more diviniation is needed such that BaseClass.some column figures out that its bound to a class, it descends to a subclass, etc, all of this assumes a completely different paradigm of everything.
This is a little woolly Mike ;-)
#1, #2, #3 are all about Column/ForeignKey objects which are not at all aware of any of these patterns, and I'm sure there are many variants, as well as for relationship() which currently doesn't implement the copy logic. Until we can get these cases covered, I would rather that our users don't waste their time experimenting and receiving mysterious deep failures only to realize hours/days later that none of their expectations are currently covered, hence the entire field of feature is disallowed *for now*.
Hmm, okay, for me, declarative is all about taking a class with
attributes and turning that into a traditional mapper/table structure,
right?
Sure, we need to copy the columns in case they're used more than once
(ie: the point of mixins!) but other than that, all the normal behaviour
should apply... and if confusion ensues on the part of the user, I'd
expect the error messages to be the same and as helpful as if they'd
"done the wrong thing" non-declaratively...
Again, I suspect I'm missing something huge here, but please hit me with
a clue stick (or better yet, a unit test or two...)
Chris
PS: Thanks for giving up on svn, now I feel truly alone :-P
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
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.
