[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. 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! |