On Jun 2, 2008, at 11:55 AM, Nebur wrote:
> >> this wont work out of the box because a particular object instance >> can >> only be in one Session at a time. For this kind of use case we >> provide a method called "merge()" which takes a dont_load=True >> argument to create local copies of objects in sessions. > > Yes, the "custom identity map" cannot be a sessions identity map, it > is a plain dict. Otherwise, the objects indeed would have to be merged > in any new session. But copies of the objects, anyway, are not desired > since identity is to be kept. >> so....since these objects are returned by create_instance(), that means they are getting sent straight into a Session. I'm assuming you didn't write your own Session, so what happens when the populate_instance() step gets run on the objects , and several concurrent threads are all issuing populate_instance() on those items at the same time ? There is no guarantee within the load of objects that there are no state changes - including internal state variables like "state.runid" which definitely will not work with concurrent modifications. Similarly, I dont see how very basic functions necessary for SQLA's operation, such as object_session(), can possibly work correctly here, since you are attempting to place the same object in multiple sessions - an object's session is identified by a single attribute placed upon the object's state (in 0.4 its on the object itself). Unless your app is using only one Session. Then it could work, however it would be extremely difficult to take advantage of multiple threads since you'd have to mutex virtually all access to that single Session. If there is some central core of "state" that you dont want to replicate, it's still possible to have many copies of an object all reference that same state using a proxying pattern. As far as hash identity, the __hash__() and __cmp__() methods work fine in that regard. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
