[DBAL-446] Type json_array can't be null Created: 13/Feb/13 Updated: 01/Apr/13 Resolved: 01/Apr/13 |
|
| Status: | Resolved |
| Project: | Doctrine DBAL |
| Component/s: | None |
| Affects Version/s: | 2.3 |
| Fix Version/s: | 2.3.3 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Jan Hruban | Assignee: | Benjamin Eberlei |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| 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 |
[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-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-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 |
[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. 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 |
[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"): ends up in a thrown exception. $qb = $this->_em->getConnection()->createQueryBuilder(); $stmt = $qb->execute(); =================== Suggested Fix: Regex on line 64 in preg_match becomes '#([:a-zA-Z0-9_] {1})#' =================== |
| 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: |
| Comment by Benjamin Eberlei [ 19/Jan/13 ] |
|
Fixed in 2.3.3 |
[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 |
| 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 |