I inherited a database which has two tables containing some similar
information, with additional differences. In terms of SQLAlchemy "Class
Inheritance Hierarchies" docs, there is an "engineer" table and a "manager"
table, but no Employee class or table. Porting to Python and SQLA
initially my "Company" equivalent just has relationships ("engineers" and
"managers") to the separate classes, and there's no inheritance involved.
This works as per the original pre-Python intent, but I'd like to treat the
common bits polymorphically in some cases, without adding/reworking tables
or breaking existing code. It looks like I can map this to concrete
inheritance? I'd move up the common fields to an AbstractConcreteBase
equivalent of Employee (using declared_attr if necessary), have the two
classes inherit from this, and give them mapper_args for a
polymorphic_identity and concrete:True? Existing relationships should
still work, but I could now do an "employees" relationship for Company to
get a mixed collection of Manager and Engineer objects for use when
appropriate?
Also, is there any ballpark estimate for the 1.0 release timeframe (weeks
vs months)? It looks like it adds additional support for declared_attr and
relationships for AbstractConcreteBase that at first glance sounds useful.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
