On Dec 4, 2008, at 11:18 AM, Guillaume wrote:
> > >> 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. getting different concrete tables to connect to a common related table, with the configuration on the base class is definitely possible and its even clear where the code to do this would occur (right at the TODO in _adapt_inherited_property)...its just some complexity that I have balked on for now. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
