[DBAL-461] Numeric() syntax in columns fails on SQL Server Created: 07/Mar/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2.2, 2.3.2
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue occurred when I tried to create entities from existing MSSQL Database. My database have several fields that are defined as "numeric" data types. When I tried to reverse engineer this data base, doctrine threw an error mentioning that doctrine numeric data types are not supported. I have attached code that I used to create entities. And error that was generated. Hope this Helps narrow down the process. One thing that ca in to notice was that the "SQLServerSchemaManager" class does not have any specific mechanism to handle "numeric" as compared to "MySqlSchemaManager".



 Comments   
Comment by Benjamin Eberlei [ 14/Mar/13 ]

Fixed





[DBAL-458] [GH-281] Upgrading doctrine/common 2.4 (via composer) Created: 04/Mar/13  Updated: 04/Mar/13  Resolved: 04/Mar/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/dbal/pull/281

Message:

This PR introduces changes necessary to make the DBAL recognize `"doctrine/common": "2.4"` as compatible as discussed in https://groups.google.com/d/topic/doctrine-dev/8WjzboENQgg/discussion

Ping @dbu



 Comments   
Comment by Benjamin Eberlei [ 04/Mar/13 ]

A related Github Pull-Request [GH-281] was closed
https://github.com/doctrine/dbal/pull/281





[DBAL-452] range is a reserved word in several platforms Created: 21/Feb/13  Updated: 15/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.3
Fix Version/s: 2.3.3

Type: Bug Priority: Major
Reporter: Michael Cummings Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux 64bit



 Description   

'range' is a reserved word for MySQL, Oracle, and on future reserved list for SQL Server as well so should really be added for escaping. Working on a new project using Doctrine accessing an external API which used it as a field and got an error when running orm:schema-tool:create on my entity with MySQL.



 Comments   
Comment by Benjamin Eberlei [ 14/Mar/13 ]

Added for MySQL and Oracle. Didn't find data on when its added to SQL Server.

Comment by Michael Cummings [ 15/Mar/13 ]

http://msdn.microsoft.com/en-us/library/ms189822.aspx under Future Keywords





[DBAL-446] Type json_array can't be null Created: 13/Feb/13  Updated: 06/Aug/14

Status: Reopened
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3, 2.4.2
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Jan Hruban Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-966 [GH-655] json_array columns should re... Resolved

 Description   

Column type json_array can be set to nullable, but if there's null in the database, it is returned as an empty array to PHP.

Null should be returned instead, as that's how the other types behave too.



 Comments   
Comment by Benjamin Eberlei [ 01/Apr/13 ]

This was fixed in 2.3.3

Comment by Joseph Wynn [ 06/Aug/14 ]

I'm seeing this behaviour again in v2.5.0-BETA3 (6d0b048). If I get time this week I can perform a bisect to figure out when it regressed.

Comment by Joseph Wynn [ 06/Aug/14 ]

Actually I don't think this was a regression; it looks like a fix was never made. I've opened a PR: https://github.com/doctrine/dbal/pull/655

Comment by Doctrine Bot [ 06/Aug/14 ]

A related Github Pull-Request [GH-655] was closed:
https://github.com/doctrine/dbal/pull/655

Comment by Doctrine Bot [ 06/Aug/14 ]

A related Github Pull-Request [GH-655] was assigned:
https://github.com/doctrine/dbal/pull/655

Comment by Marco Pivetta [ 06/Aug/14 ]

Re-opened, as this behavior seems reproducible also in 2.4.x

Comment by Steve Müller [ 06/Aug/14 ]

It was never fixed. That seems to have been a misunderstanding here. As pointed out by Marco Pivetta changing this behaviour is a BC break and can't be fixed before 3.0.





[DBAL-436] Logger should specify connection used in a master/slave situation Created: 31/Jan/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.2
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Jarrod Nettles Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

Suppose there is a master connection with four slaves specified. Connections are being handled by the Doctrine\DBAL\Connections\MasterSlaveConnection class. Under the current implementation, all queries are logged under the "master" connection, even queries that are routed to the slaves by the Doctrine\DBAL\Connections\MasterSlaveConnection class.

Since slave connections are separate, distinct connections, queries should be logged appropriately under their respective connections.



 Comments   
Comment by Benjamin Eberlei [ 01/Apr/13 ]

Two reasons why this is not feasible:

1. We actually don't ship loggers on our own, so if you want you can implement this yourself. We wouldn't have a way to "add" this, we only provide the interface.

2. However the logger does not have access to the connection to find out which slave or master its currently using, you can create a logger that has a "setConnection($conn)" method and call this during bootstrapping the logger+connection.





[DBAL-416] [GH-249] Fixed doModifyLimitQuery for SQLServerPlatform Created: 18/Jan/13  Updated: 20/Jan/13  Resolved: 20/Jan/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of norzechowicz:

Url: https://github.com/doctrine/dbal/pull/249

Message:

It seems that there is a problem in SQLServerPlatform ``doModifyLimitQuery`` method.
I can't use Doctrine ORM Paginator because of wrong position of ``DISTINCT`` statement in final limit subquery, here is the exception message I'm getting.
``SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'DISTINCT'.``

My proposition is to change ``doModifyLimitQuery`` result from:

``SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY username DESC) AS doctrine_rownum, * FROM user) ...``

into:

``SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY username DESC) AS doctrine_rownum FROM user) ...``



 Comments   
Comment by Benjamin Eberlei [ 20/Jan/13 ]

A related Github Pull-Request [GH-249] was closed
https://github.com/doctrine/dbal/pull/249





[DBAL-364] [GH-216] Fixed SQL placeholder parsing Created: 11/Oct/12  Updated: 19/Jan/13  Resolved: 19/Jan/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of a-nik:

Url: https://github.com/doctrine/dbal/pull/216

Message:

Fixed comment on 'getPlaceholderPositions' method
Fixed error on escaped quote mark inside an SQL expression



 Comments   
Comment by Fabio B. Silva [ 19/Jan/13 ]

Closed in favor of GH-113

Comment by Benjamin Eberlei [ 19/Jan/13 ]

Fixed in 2.3.3





[DBAL-231] Doctrine\DBAL\SQLParserUtils::getPlaceholderPositions() - regex Created: 05/Mar/12  Updated: 19/Jan/13  Resolved: 14/Mar/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2
Fix Version/s: 2.3.3
Security Level: All

Type: Bug Priority: Major
Reporter: Ivo Mandalski Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Fedora-16, Zend Serve CE, PHP 5.3.5



 Description   

Running the following SQL (note the named parameter ":account_id"):
===================
SELECT count('*') as cnt FROM feed f INNER JOIN orders_accounts oa ON oa.order_id = f.feed_id INNER JOIN users u ON u.id = f.user_id WHERE oa.account_id = :account_id AND f.feed_type='order' ORDER BY f.create_date DESC
===================

ends up in a thrown exception.
This SQL was generated by using the Query Builder

$qb = $this->_em->getConnection()->createQueryBuilder();
$qb->select('count(\'*\') as cnt');//I know this is bad
$qb->from('feed', 'f');
$qb->innerJoin('f', 'orders_accounts', 'oa', 'oa.order_id = f.feed_id');
$qb->innerJoin('f', 'users', 'u', 'u.id = f.user_id');
$qb->where('oa.account_id = :account_id AND f.feed_type=\'order\'');
$qb->setParameter('account_id', $accountId, \PDO::PARAM_INT);

$stmt = $qb->execute();
$res = $stmt->fetchAll(\PDO::FETCH_COLUMN);

===================
string(82) "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'NULL_id' in 'where clause'"
string(3168) "#0 /var/www/cake_to_zf/library/Doctrine/DBAL/Connection.php(628): PDOStatement->execute()
#1 /var/www/cake_to_zf/library/Doctrine/DBAL/Query/QueryBuilder.php(185): Doctrine\DBAL\Connection->executeQuery('SELECT count('*...', Array, Array)
#2 /var/www/cake_to_zf/library/of/doctrine/SqlQueryBuilderPaginatorAdapter.php(69): Doctrine\DBAL\Query\QueryBuilder->execute()
#3 /var/www/cake_to_zf/library/Zend/Paginator.php(1060): of\doctrine\SqlQueryBuilderPaginatorAdapter->count()
.......

Suggested Fix:

Regex on line 64 in preg_match becomes '#([:a-zA-Z0-9_]

{1}

)#'
Added was an "_" ...

===================



 Comments   
Comment by Benjamin Eberlei [ 14/Mar/12 ]

Fixed

Comment by Benjamin Eberlei [ 14/Mar/12 ]

Merged in 2.1.x and 2.2 branches.

Comment by Andrew Vit [ 24/Mar/12 ]

I already fixed this in my reworking of the SqlParserUtils last month. See pull request and confirm that this issue was fixed there, together with other parsing problems:

https://github.com/doctrine/dbal/pull/113

Comment by Benjamin Eberlei [ 19/Jan/13 ]

Fixed in 2.3.3





Generated at Thu Oct 23 18:40:15 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.