On Aug 12, 2010, at 2:41 PM, Faheem Mitha wrote: > objects among threads, they reference their owning session in order > to load additional state. If you pass objects between threads you > should merge() them into the current thread's session first, then > use that result. > > I see. That's very enlightening. Can one query such objects to > determine their owning session? Some attribute, perhaps?
see http://www.sqlalchemy.org/docs/session.html#frequently-asked-questions > >>> Can you confirm that there is no reason not to use scoped sessions >>> everywhere, even in serial execution? Of course, if that is the >>> case, then I wonder why non-scoped sessions are used at all. > >> scoped_sessions are usually the default choice for web applications > since they desire distinct transactions and object state for > individual threads. They are overkill and potentially confusing or > inappropriate in other situations, however. > > I'm not sure why they would be potentially confusing. What are some of > the downsides? I'd have thought that not having shared state was less > confusing. the scoped_session is a proxy object to the "real" object. It is less confusing for those unfamiliar with thread locals and proxy objects to deal with a Session directly. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
