Re: [sqlalchemy] a few questions on transactional events

2017-05-11 Thread Jonathan Vanasco
So the Pyramid debug toolbar system catches the before_cursor_execute to set up a timing start, and after_cursor_execute to calculate the duration. It's decent support for approximated query timing. It didn't log any of the other events though, so I'm working on a solution to log them. The ti

Re: [sqlalchemy] a few questions on transactional events

2017-05-11 Thread mike bayer
On 05/10/2017 10:22 PM, Jonathan Vanasco wrote: On Wednesday, May 10, 2017 at 8:09:22 PM UTC-4, Mike Bayer wrote: no return value needed perfect you mean, the commit() method itself how long does that take? You'd probably do a time.time() check before and after calling the m

Re: [sqlalchemy] a few questions on transactional events

2017-05-10 Thread Jonathan Vanasco
On Wednesday, May 10, 2017 at 8:09:22 PM UTC-4, Mike Bayer wrote: > > no return value needed > perfect > you mean, the commit() method itself how long does that take? You'd > probably do a time.time() check before and after calling the method (or > use timeit.timeit to do the same). >

Re: [sqlalchemy] a few questions on transactional events

2017-05-10 Thread mike bayer
On 05/10/2017 07:55 PM, Jonathan Vanasco wrote: I have a few basic questions on the "transactional" events as I try to extend pyramid's logging system to grab them. 1. do the events need to return anything, or can they just sit there and be dumb? for example: @event.listens_for(Engin

[sqlalchemy] a few questions on transactional events

2017-05-10 Thread Jonathan Vanasco
I have a few basic questions on the "transactional" events as I try to extend pyramid's logging system to grab them. 1. do the events need to return anything, or can they just sit there and be dumb? for example: @event.listens_for(Engine, "commit") def _commit(conn): pass some