[sqlalchemy] Re: query.filter and entity_name
Thank you Michael, I will use subclassing instead. A mention of this technique in the documentation (in the Multiple Mappers for One Class) would be great, as it is the place I was looking for a solution to my problem when I found entity_name. Best regards, Christophe 2008/7/7 Michael Bayer [EMAIL PROTECTED]: 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. 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. 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: query.filter and entity_name
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. 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. 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: query.filter and entity_name
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 -~--~~~~--~~--~--~---
