On Monday 07 July 2008 18:10:19 Michael Bayer wrote: > It's currently preferred if you didn't use entity_name since it > works quite poorly and even worse in 0.5, and we'd like to remove > it - it has built-in undefined behavior in that its not determined > which set of attribute instrumentation gets applied to the class. i had some idea about this instrumentation stuff... it's theoretical as i didnt have time to try it - and since i'm sort-of out of job i probably wouldnt have a chance to try it.
but anyway. seems sooner or later one ends in need of multiple aspects requireing instrumentation, e.g. DB-backend, dependency-calculations (trelis or similar), automatic typing/validation, temporal view (single version vs history of versions of one "object" vs history of many "objects" of same type), etc. i was thinking about having some super-instrumentation, which contains all the instrumentations, and one can choose which one(s) to apply at hand. This might be a bit strange; most of the instrumentations would be applied at same time, probably in some preset order. i'm not sure how exactly one could switch between DB-entity-instrumentations, but say right now i need to switch between different temporal views, so there should be a way - via default context, or special attribute/subattribute or something. it's just an idea - which has been probably invented long time ago somewhere else. The whole point is to have everything attached to same class - which may or may not be useable/preferable. Probably in most cases an aspect can be added without needing class-awareness. > This feature is an artifact of Hibernate which we copied at some > point but doesn't apply well to Python where subclassing does not > place a significant structural burden on code (and multiple > inheritance makes it even less burdensome). Mapping to individual > subclases is much more straightforward - its the difference between > your instance which is of class A plus magic entity name attribue > B, versus, your instance is of class B subclassing A. The object > has "state" which represents the "entity_name" in either case. can u have 2 classes with 2 different mappers over same table? i guess yes? then its really not needed. > We haven't yet removed entity_name from 0.5 because I'm waiting for > someone to have a truly compelling argument for it. > > On Jul 7, 2008, at 6:45 AM, Christophe de VIENNE wrote: > > Hi, > > > > I'm having trouble using entity_name. > > > > I have two mappers for the same class, one of them having an > > entity_name="legacy". > > > > If I do a query with the "legacy" mapper, I cannot figure how to > > filter on properties. Ex: > > > > session.query(MyClass, entity_name='legacy').filter( > > MyClass.arelationprop.has( <criterions> )) > > > > In this case, the table from the default mapper is always getting > > in the way. > > > > I think I am not using properly the alternate mapper, but cannot > > find any example. > > > > Thanks a lot, > > > > Christophe > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
