> sure this is called "concrete table inheritance". Though when you > make a relation to Order, you need to declare these separately for > CorporateCustomer and PrivateCustomer since the connection from a > relational perspective is different. When concrete inheritance uses > an abc, it maps to a union of the subtables so that you can load > polymorphically. To do that with declarative you'd also have to > create the Table objects separately and pull them in to each class > using __table__. > > So with those limitations, if it were me I wouldn't use the concrete > inheritance feature unless i needed to load "Customer" objects > generically, I'd instead use "Customer" as a mixin class stated after > the declarative base class.
Which prety much means no generic query for Customer objects ... I'll go down the concrete inheritance path and create a couple of views for handling my abstract classes. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
