On Dec 13, 2007 12:29 PM, Allen Bierbaum <[EMAIL PROTECTED]> wrote: > 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.
I think I am going to use this second method because I don't want to force a database reload during the "merge". Instead I want to use the detached instance for a while. My foreground thread can get by using the loaded version of a couple of the fields of the object in the detached state. Then if/when the code needs to see additional data bout the record (through relationship mappings), I will use update to attach to the foreground session. The one question I have here though is, how can I make the update() call that reattaches it to the foreground session automatically reload the entire record from the database (ie. ignore any local modifications)? Do I have to call update() followed by refresh()? 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 -~----------~----~----~----~------~----~------~--~---
