> On Dec 6, 2014, at 3:38 AM, YKdvd <[email protected]> wrote: > > 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?
yes > 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? AbstractConcreteBase is a tricky class and there’s some improvements in 1.0 for that (see the end of http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html#improvements-to-declarative-mixins-declared-attr-and-related-features <http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html#improvements-to-declarative-mixins-declared-attr-and-related-features> for what won’t work very well in 0.9), it might be a good idea for you to at least experiment with classical mappings first just to make sure things work they way you want (and you can always mix classical mappings with declarative anyway, they have the same end result). The example for how to get relationships to concrete classes polymorphically (of course with the company/engineer/manager example!) is at http://docs.sqlalchemy.org/en/rel_0_9/orm/inheritance.html#relationships-with-concrete-inheritance <http://docs.sqlalchemy.org/en/rel_0_9/orm/inheritance.html#relationships-with-concrete-inheritance>. > > 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. the ABC improvements are conveniences, you can still do these patterns in 0.9 you just need to attach the relationships after the fact. the timeframe is when everything at https://bitbucket.org/zzzeek/sqlalchemy/issues?status=new&status=open&milestone=1.0 <https://bitbucket.org/zzzeek/sqlalchemy/issues?status=new&status=open&milestone=1.0> is either resolved, or moved off to a different milestone. Many of these already have code written, where the work in getting these merged is in writing tests and documentation. > > -- > 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 [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/sqlalchemy > <http://groups.google.com/group/sqlalchemy>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
