On May 26, 9:43 am, Michael Bayer <mike...@zzzcomputing.com> wrote: > but if after_commit() is called and after_flush() is not called, that means > nothing was flushed.
Right. So, for example, for a request that only does SELECTs, nothing will be flushed, but after the request, I still do session.commit(), because hasn't a transaction been started automatically? Or does SQL Alchemy only start a transaction if there are writes to do? > Usually the way to go about this is to populate a distinct collection of > events when objects are created: > > foo = MyObject() > Session.add(foo) > add_commit_event(some_callable) > [snip] > the session extension then pops from _after_commit_tasks. Apart from coupling the two parts of the code, which is what I was trying to avoid, what's the difference here? In after_commit, session._after_commit_tasks would, in this case, contain the same as session.new, right? > You can expire the attribute manually ahead of time if you want it to reload > its value (should be fine within after_commit). I think this is what I need. I'll give it a go. Thanks. -- 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.
