On Jul 22, 2011, at 8:49 AM, jasonmclose wrote: > > my desire is to emulate this with sqlalchemy,
Ok "emulate", meaning, you no longer want to use Postgresql INHERITS and want SQLA to deal with the multiple tables ? Assuming I haven't forgotten how INHERITS works (I've not used it myself), concrete table inheritance is most similar here, i.e. that each table maintains all columns. It's an awkward mode of usage as each class needs to query from a different table, and to query all classes at once requires a UNION. Docs are at http://www.sqlalchemy.org/docs/orm/inheritance.html#concrete-table-inheritance . Concrete is also difficult to map with declarative at the moment, if you're using a polymorphic_union, since the selectable needs to be known up front and needs the related tables in order to be constructed - theres a recipe at http://www.sqlalchemy.org/trac/wiki/UsageRecipes/DeclarativeAbstractConcreteBase which may help. Joined or single table inheritance are much easier to use patterns with SQLAlchemy as well as other ORMs that do inheritance, they're described in those docs as well. For the relationship with concrete, its again tricky (and with single/joined, quite simple). A discussion of this is here: http://www.sqlalchemy.org/docs/orm/inheritance.html#relationships-with-concrete-inheritance . Basically every table has to have the foreign key back to the referenced table, as well as its own relationship(). If you wanted to map directly on top of the PG INHERITS structure, you'd again use concrete inheritance, map to each table explicitly, and you'd get the selection of polymorphic objects for free using PG's built in behavior. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
