On Dec 13, 2007 10:47 AM, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > > On Dec 13, 2007, at 9:55 AM, Allen Bierbaum wrote: > > > > > In my current application I am running a rather expensive query in a > > background thread, but then I need to use the results in the > > foreground thread. The object I find has a great deal of lazy > > evaluated properties that link it to several other mapped objects. As > > it stands now, the application is only following the lazy properties > > when it uses the object in the primary thread. The has multiple > > engines connected to multiple databases. I have a separate session > > for each database for each thread. (Note: right now I am doing this > > manually but I am debating whether I should be using something like > > SessionContext.) > > > > What I am worried about is that by querying the initial parent object > > in the background thread and then using it's lazy props in the > > foreground thread, I think SA is probably using the background session > > to evaluate these links. > > > > Is there a recommended way to deal with a situation like this? In > > other words, what is the recommended practice for moving, reusing > > objects from a session across multiple threads. Is there some way to > > remap the object and attach it to the foreground session? > > > > theres two general options here. the most appropriate way to move > the object between sessions is to use session.merge(). this will > create a copy of the object in the target session, which is returned, > leaving the old one unchanged, so that it can additionally be "merged" > elsewhere. > > as of version 0.4.1 we added a flag to merge called "dont_load" which > prevents merge() from reloading the instance from the database upon > merge (the classical behavior of this method is that it loads the > current data from the database which is merged with the given data). > so setting dont_load=True will prevent these loads from happening. we > also have some fairly important fixes to dont_load=True in the current > trunk which will be out in version 0.4.2, so if you are getting into > heavy merge() usage and you need to use the dont_load flag (which is > strictly for performance reasons), you might want to go on trunk for > awhile. > > The other option here is to move the object completely from the > background to the foreground session. to do this, you would expunge() > it from the background session, and then update() it into the target > session. this is a "simpler" operation than merge since nothing is > being copied. but youd want to ensure the objects youre moving werent > part of some larger collection thats still sitting in the background > session. > > hope this helps...
That helps. Thanks. I will try to start using merge along with SessionContext to fix up my threading issues. Thanks, Allen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
