On Sep 3, 2008, at 11:25 PM, Michael Bayer wrote:
> > This pattern doesnt entirely make sense - the "citizen_type" and > "employee_type" columns seem superfluous and redundant against each > other, since we really can't load Engineer rows without querying all > three tables. In that sense it takes on all the limitations of > concrete table inheritance, which doesnt use a "type" column at the > table level. > after a night's sleep, let me backtrack a bit. having discriminiator columns in all superclass tables would probably still be effective in the way we use discriminiator columns right now. the mapper would basically have to use one or the other in the case where more than one is available (like, querying subclasses of Engineer). You would want to share the primary key column across all three tables though (i.e. foreign key in the subclass table, like the link I mentioned) so that the primary key takes on the same form no matter what class you're looking at - that helps inheritance a great deal since its one of the assumptions SQLA makes. The change to SA's internals would still be pretty heavy and its hard to say what kinds of roadblocks would appear when developing such a feature. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
