Basically, we have some actions that are performed by direct database access that happen in a "deferred" state. When we flush, we want to process these deferred actions. So it looks like we will need to continue overriding the session flush.
Thanks for your quick reply. Max On Wed, 2010-07-21 at 12:12 -0400, Michael Bayer wrote: > On Jul 21, 2010, at 10:37 AM, Max wrote: > > > Hi Group, > > > > We are currently working on an issue where we want to use the > > SessionExtension ability. However, we run into a problem when our > > session.flush() has no changes to be made. However at the same time > > we > > have processing that we want to happen after the flush in the form of > > deferred operations. We tried overriding the after_flush_postexec but > > this does not get fired in the case of a non-dirty session. We also > > found that other of the extension methods do not get fired when the > > session isn't dirty. Is there a specific reason for this? We would > > like to avoid having to override the flush method to get the proper > > functioning. > > > > Basically, I think the extensions should fire regardless of the state > > of > > the session. But that is just me, I am not sure if there are reasons > > to > > not want this for other cases. > > The extensions refer to when a flush of pending state actually takes place. > Nothing happens for an empty flush(), since empty flushes are extremely > common the library conserves as many method calls as possible for these. > > If you need something to happen every time the actual flush() method is > called, you would need to subclass Session and override flush() to perform > your additional tasks. sessionmaker() accepts a "class_" argument for this > purpose. Or, call a distinct method of your own (on a Session subclass or > not), since it seems like you have special semantics that you are attaching > to the flush() call that aren't normally there. For example - flush() is > called for every execution of Query. What does your extension do that it > needs to execute every time a Query on an otherwise clean session executes a > statement ? If three statements are executed in succession, you extension > then needs to do something for all three ? > > -- 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.
