[DBAL-38] Unused DBAL\Events (preExecute, postExecute)... Created: 23/Dec/09  Updated: 15/Aug/10  Resolved: 15/Aug/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-BETA3
Fix Version/s: 2.0.0-BETA4

Type: Improvement Priority: Minor
Reporter: Hannes Magnusson Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux



 Description   

The ORM has a neat collection of Events, but the DBAL doesn't have any.
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.
The only event/loging seems to be the ->logSql() event.

A preExecute & postExecute events would be great for timing/profiling queries.



 Comments   
Comment by Jonathan H. Wage [ 20/Mar/10 ]

Roman, do we want to implement these? If so I can produce a patch.

Comment by Roman S. Borschel [ 20/Mar/10 ]

I'm not sure of their usefulness. Hannes mentions timing queries but this is not really possible since many queries are not executed through execute()/executeUpdate() but rather through prepare() and then execute() on the Statement.

Are there any other good use-cases?

Comment by Benjamin Eberlei [ 20/Mar/10 ]

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.

Comment by Roman S. Borschel [ 20/Mar/10 ]

Personally I find timing queries in php code not very useful since its very inaccurate and you dont get any further information.

Comment by Christian Heinrich [ 21/May/10 ]

If there are no other use cases, +1 for removal.

Comment by Christian Heinrich [ 21/Jul/10 ]

Has any decision been made on whether to remove or not?

Comment by Roman S. Borschel [ 28/Jul/10 ]

I think they can be removed as the DBAL SQLLogger now also records the execution time.

Comment by Benjamin Eberlei [ 15/Aug/10 ]

Removed!

Generated at Thu Apr 17 15:33:17 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.