[DBAL-39] SQL Logger should log the last failed query Created: 04/Aug/10 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: | Major |
| Reporter: | Michael Ridgway | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The SQL Logger is only called after a query has been executed (this was changed to allow profiling of the queries). This makes it difficult to determine which query has failed. The commit that changed the functionality is at: http://github.com/doctrine/dbal/commit/fe0f0e4b8c6c5308cab3d683c552f61317de7067 It seems that the logger interface needs to be changed to two functions, a pre-query function and a post-query function. Profiling should be handled by the logger if it chooses and not by the connection class. |
| Comments |
| Comment by Benjamin Eberlei [ 15/Aug/10 ] |
|
After lots of thinking i changed the Logger again to have a startQuery() and a stopQuery() method now. |
[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! |
[DBAL-35] PDO_Sqlsrv bug in _constructPdoDsn() Created: 21/Jul/10 Updated: 31/Aug/10 Resolved: 31/Aug/10 |
|
| Status: | Resolved |
| Project: | Doctrine DBAL |
| Component/s: | Drivers |
| Affects Version/s: | 2.0.0-BETA2 |
| Fix Version/s: | 2.0.0-BETA4 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Bostjan Oblak | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Environment: |
Windows 7, Zend Server CE, Sql Server driver for PHP v2 |
||
| Description |
|
When connection to mssql server with pdo_sqlsrv driver you get: [PDOException] SQLSTATE[IMSSP]: The DSN string ended unexpectedly. Sample $connectionOptions: $connectionOptions = array(
'dbname' => 'AdventureWorks',
'user' => 'sa',
'password' => 'sa_password',
'host' => 'local',
'driver' => 'pdo_sqlsrv'
);
Error is in Doctrine\DBAL\Driver\PDOSqlsrv\Driver in function _constructPdoDsn(array $params). $dsn = 'sqlsrv:(';
instead of $dsn = 'sqlsrv:server=(';
as written in offical Microsoft help which come with SQL Server Driver For PHP v2. |
| Comments |
| Comment by Benjamin Eberlei [ 21/Jul/10 ] |
|
@Juozas can you evaluate this and possibly apply a fix? |
| Comment by Benjamin Eberlei [ 31/Aug/10 ] |
|
Fixed |