http://www.doctrine-project.org/jira This file is an XML representation of an issue en-us 5.2.7 850 21-02-2013 http://www.doctrine-project.org/jira/browse/DBAL-38 Doctrine DBAL <p>The ORM has a neat collection of Events, but the DBAL doesn't have any.<br/> There is an DBAL/Events.php class which has defined constants for preExec, postExec, preExecute and postExecute (similar to ORM/Events.php), but these seem to be completely unused.<br/> The only event/loging seems to be the -&gt;logSql() event.</p> <p>A preExecute &amp; postExecute events would be great for timing/profiling queries.</p> Linux DBAL-38

Unused DBAL\Events (preExecute, postExecute)...

Improvement Minor Resolved Fixed Benjamin Eberlei Hannes Magnusson Wed, 23 Dec 2009 13:00:15 +0000 Sun, 15 Aug 2010 14:59:41 +0000 Sun, 15 Aug 2010 14:59:41 +0000 2.0.0-BETA3 2.0.0-BETA4 0 1 <p>Roman, do we want to implement these? If so I can produce a patch.</p> <p>I'm not sure of their usefulness. Hannes mentions timing queries but this is not really possible since many queries are <b>not</b> executed through execute()/executeUpdate() but rather through prepare() and then execute() on the Statement.</p> <p>Are there any other good use-cases?</p> <p>Hm timing and profiling could either be done with vendor-tools or we extend the SqlLogger interface a bit like i proposed in a previous issue. I dont see any other use-cases.</p> <p>Personally I find timing queries in php code not very useful since its very inaccurate and you dont get any further information.</p> <p>If there are no other use cases, +1 for removal.</p> <p>Has any decision been made on whether to remove or not?</p> <p>I think they can be removed as the DBAL SQLLogger now also records the execution time.</p> <p>Removed!</p>