On Aug 14, 2010, at 3:54 PM, Michael Hipp wrote: > On 8/14/2010 2:29 PM, Michael Bayer wrote: >> The approach above may be fine for your needs but I wouldn't encourage it. >> The demarcation of transaction boundaries shouldn't be an ad-hoc thing IMO >> and granular functions shouldn't be deciding whether or not they are setting >> up a transaction. > > Thanks. Yes, I was beginning to suspect such. Makes more sense to manage the > session and commit/rollback issues at the top of the call stack. I was trying > too hard to not have to pass the session down in argument lists, but looks > like I should.
well, you can either call object_session() in the methods to get the current object's session, or set up a registry like scoped_session that you access globally - I'd try to avoid having to pass the session around too. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
