On Nov 21, 2010, at 4:41 PM, Eric Ongerth wrote: > I must be in a "search blind spot", I'm having trouble finding > references and examples for this pattern, though I feel certain I've > seen examples around the sqlalchemy literature a couple of times > before. > > I have a table of Companies, and then further tables of Manufacturer > and Vendor info which apply to some companies. So a company can be > stored just as a company, or as a company that happens to be a > manufacturer, and/or happens to be a vendor. I don't want the > manufacturer and vendor designations to be exclusive of each other; it > should be possible for a company to be both.
The thing I pointed someone to the other day regarding multiple inheritance in general is at http://www.agiledata.org/essays/mappingObjects.html#MappingMultipleInheritance . My general attitude about that example is "yeah great, go nuts !". i.e. if someone wants to get into it, great, good luck, but I haven't personally ever had any situation that called for something that complex and if I did, I'd probably try to get around it somehow. Maybe someday I'll actually need the feature though, then I'll figure out how to do it generically, then it will be the next big SQLA feature everyone needs, who knows. > > I thought of just having a boolean field on the Company table for each > 'child' type. So (company.manufacturer == True) would tell me it's > safe to write to or read from attributes whose storage is in the > manufacturer info table. Likewise, (company.vendor == True) would > indicate that it's safe to write to or read from attributes whose > storage is in the vendor info table. And of course some companies > will be filed as neither, so I won't attempt to access mfr or vendor > info about them. so I think if you are trying to get multiple tables to compose into a single type, its likely very possible using a combination of relationship() and association_proxy(). relationship() to maintain the linkages to other tables, association_proxy or something similar (perhaps like the hybrid example, after all we are just using Python attribute tricks) to create a one-level-of-names type of facade. > > Regular SA joined-table inheritance doesn't work this way since it > requires a discriminator column taking a single value at a time. > Still I would love to use joined-table inheritance if I could. Is > there a way? joined inheritance might be involved, but in a practical sense you have to think about what your SELECT queries are going to look like if locating a record requires spanning across three or four tables. -- 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.
