On Wed, May 30, 2012 at 8:39 PM, Michael Bayer <mike...@zzzcomputing.com> wrote: > well yes, the way you're doing this is entirely the opposite of how the ORM > is designed to function. The Session has been developed in order to work > in an intelligent manner with full graphs of interrelated objects, all > coordinated under the umbrella of a transaction which applies atomicity and > isolation to the full series of operations. An individual object loaded > from a Session is in fact an extension of that Session's state, which is in > turn an extension of the state of the current transaction within the > database, all kept in sync mostly automatically. When you continuously > break this connection between a whole series of interconnected objects > you'll run into not just lots of problems keeping objects associated with > continuously new transactions, but also horrendous performance from due to > the excessive number of commits and re-acquisition of new > connections/transactions. > > In general, the Session is typically used in a "bounding" sense, its > lifespan beginning before you work with any objects, and ending only after > you've completed the work with those objects. I frequently use the > metaphor here that the Session is the table setting and the objects are the > meal.
Thing is, in order to work with a large volume of objects, you're forced to do this, otherwise the session can grow uncontrollably. When you separate the operation to work in batches, you almost always have some objects that have a lifespan larger than a single batch, and then a single session. Another case in which an object's lifespan can exceed the session's, is when you want to implement caching with objects of your data model - cached values will have come from other sessions than the current one, and things get horribly messy. And, finally, the "long transaction" pattern, which luckily is a lot easier to solve. If the OP is using that pattern, it's just a matter of reattaching detached objects to the session. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
