[DBAL-1050] [GH-729] Support for database URLs Created: 26/Nov/14  Updated: 26/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

With a bunch of tests.

Of note:

1. in the case of information present in both URL and "normal" parameters, I'm currently giving priority to the information from the URL; IMO this makes more sense than vice versa (base info would be defined in params, and each developer or environment has a URL that may or may not override that base info, such as charset)
1. the syntax for SQLite is `sqlite:///relativepath.db` or `sqlite://ignoredhost/relativepath.db` for relative, and `sqlite:////tmp/absolutepath.db` or `sqlite://ignoredhost//tmp/absolutepath.db` for absolute paths to the database file (I went back and forth on this, but this way is easier and more consistent; https://github.com/kennethreitz/dj-database-url does the same)
1. extra query params are simply "copied" into `$params` verbatim; makes sense IMO especially considering point number 1






[DBAL-1049] [GH-728] Ignore pseudo-system objects in table list Created: 25/Nov/14  Updated: 25/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

These objects are created by turning on replication and they have column types (sysname, xml) that are not supported by Doctrine.

According to Microsoft's support, these are "'pseudo-system' object[s]" that appear in the User Table type instead of the System Table type.

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/135ec547-2214-4da3-bd42-5c458759e144/sysobjectscategory

This issue is very similar to http://www.doctrine-project.org/jira/browse/DBAL-114 so I handled it in the same section of the code as the fix for that issue.






[DBAL-1043] [GH-725] Exclude tables with table_type of VIEW Created: 10/Nov/14  Updated: 24/Nov/14  Resolved: 24/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This excludes views registered by PostGIS 2.x like geography_columns, geometry_columns, raster_columns and raster_overviews.

The table_name != 'geometry_columns' is kept for PostGIS 1.5 compatibility. The type changed to VIEW in PostGIS 2.0.

Failing tests: https://travis-ci.org/jsor/dbal/builds/40528525 (See #724)



 Comments   
Comment by Doctrine Bot [ 24/Nov/14 ]

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

Comment by Steve Müller [ 24/Nov/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/40fd004725b4aa902aea170cd15152b06a6faba0

Comment by Doctrine Bot [ 24/Nov/14 ]

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





[DBAL-1041] DBAL exception when detecting unknown database types is too vague Created: 09/Nov/14  Updated: 20/Nov/14  Resolved: 10/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Tom Vogt Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

OS X 10.9



 Description   

Using Symfony, updating a schema with

app/console doctrine:schema:update --dump-sql

gives me this error after I updated Doctrine today:

  [Doctrine\DBAL\DBALException]                                                                           
  Unknown database type name requested, Doctrine\DBAL\Platforms\PostgreSQL92Platform may not support it.  

The exception message verbosity is insufficient.



 Comments   
Comment by Marco Pivetta [ 10/Nov/14 ]

Reverted to minor

Comment by Marco Pivetta [ 10/Nov/14 ]

The confusion here comes from your database type, which is indeed "name" in your case.

See https://github.com/doctrine/dbal/blob/a2e87c57a9843f07e8e6d6e57fe0fff965c0f4ac/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L423 for reference.

Also, please take few moments more before opening an issue next time.
We are all doing what we can in our free time here, and raging doesn't help anyone.

Comment by Tom Vogt [ 10/Nov/14 ]

Sorry for the wording, I didn't intend to rage or insult anyone, I'm just very direct when I report a problem.

I'm not sure your assessment is correct. I do NOT have any database type called "name". I have a few fields with a name "name", but none where the TYPE is set to "name" (which would, obviously, be an invalid type).

for example, I have definitions like this:
<field name="name" type="string"/>

But nowhere in the code (verified by global search) is the TYPE ever set to "name".

Comment by Tom Vogt [ 10/Nov/14 ]

I was half-wrong there. I don't have any entity definitions with that type, but since I use PostGIS, there are a few views that use "name" as a column type.

using the undocumented schema_filter fixes it. Still, if this error would provide the table name, it would be a massive help. To find the problem, I had to put debug code into vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php

Comment by Marco Pivetta [ 11/Nov/14 ]

What can eventually be done is catching and re-throwing a more specialized exception in the location where it may occur. If you feel the need for it, then please open a pull request directly.

Comment by Jon West [ 20/Nov/14 ]

For those who are coming across this specific error and are using PostGIS, add this to your config in appropriate place.

doctrine:
dbal:
schema_filter: ^spatial_ref_sys





[DBAL-1048] Function based index Created: 20/Nov/14  Updated: 20/Nov/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Minor
Reporter: Grégoire Paris Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql


 Description   

I would like to create a function-based index, but it does not seem to be possible ATM. The final goal is to be able to have case insensitive string filters with Postgresql without losing performance.

I tried this mapping :

  indexes:
        my_entity_name_index:
            columns: [ LOWER(name) ]

But here is what doctrine answers :

[Doctrine\DBAL\Schema\SchemaException]

There is no column with name 'LOWER(name)' on table 'my_entity'.



 Comments   
Comment by Marco Pivetta [ 20/Nov/14 ]

I don't think that we can provide platform-specific index column name support here.





[DBAL-1047] doctrine:schema:update ignores index names set on Entity via Annotation Created: 20/Nov/14  Updated: 20/Nov/14  Resolved: 20/Nov/14

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

Type: Bug Priority: Minor
Reporter: webDEVILopers Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: schematool
Environment:

"php": ">=5.3.3",
"symfony/symfony": "2.5.*",
"doctrine/orm": "~2.4",
"doctrine/doctrine-bundle": "~1.2"


Issue Links:
Duplicate
duplicates DDC-2989 ORM should allow custom index names f... Open

 Description   

I am naming my indexes via annotations in my entity:

/**
 * @ORM\Entity
 * @ORM\Table(name="delivery_notes", indexes={
 *  @ORM\Index(name="location_idx", columns={"location_id"}),
 *  @ORM\Index(name="user_idx", columns={"user_id"}),
 *  @ORM\Index(name="compartment_idx", columns={"compartment_id"})
 * })
 */
class DeliveryNote

When running doctrine:schema:update the names are ignored (at least when they don't exist yet):

CREATE INDEX IDX_1110401E64D218E ON delivery_notes (location_id);
CREATE INDEX IDX_1110401EA76ED395 ON delivery_notes (user_id);
CREATE INDEX IDX_1110401E6136A935 ON delivery_notes (compartment_id);

Is this an expected behaviour?



 Comments   
Comment by Marco Pivetta [ 20/Nov/14 ]

Duplicate of DDC-2989





[DBAL-95] Interbase/Firebird support Created: 26/Feb/11  Updated: 13/Nov/14

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 5
Labels: None


 Description   

Implemented support for Interbase/Firebird dialects






[DBAL-1046] Broken link Created: 12/Nov/14  Updated: 12/Nov/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.5
Fix Version/s: None

Type: Task Priority: Minor
Reporter: ted bohus Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

On the website, the link to download Doctrine DBAL 2.3.5 doesn't work...

http://www.doctrine-project.org/downloads/DoctrineDBAL-2.3.5-full.tar.gz

Thanks






[DBAL-906] [GH-605] Removed unused field Created: 13/May/14  Updated: 12/Nov/14  Resolved: 13/May/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 13/May/14 ]

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

Comment by Marco Pivetta [ 13/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/6e1c54d4b5c007b42a8bb724941cca323d512de6

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DBAL-783] [GH-508] [DDC-2310] Fix evaluation of NOLOCK table hint on SQL Server Created: 13/Jan/14  Updated: 11/Nov/14  Resolved: 14/Jan/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: 2.5
Security Level: All

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

Issue Links:
Reference
relates to DDC-2310 Recent changes to DBAL SQL Server pla... Resolved
is referenced by DBAL-976 [GH-663] [DDC-2310] [2.4] Fix evaluat... Resolved

 Description   

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

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

Message:

This PR is complementary to https://github.com/doctrine/doctrine2/pull/910.
ORM passes `null` to `AbstractPlatform::appendLockHint()` as `$lockMode` which should not evaluated to `LockMode::NONE` unless `0` is explictly given. Otherwise ORM appends `WITH (NOLOCK)` to all queries even though, no query lock hint is set.



 Comments   
Comment by Doctrine Bot [ 14/Jan/14 ]

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

Comment by Doctrine Bot [ 31/Jan/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DBAL-976] [GH-663] [DDC-2310] [2.4] Fix evaluation of NOLOCK table hint on SQL Server Created: 20/Aug/14  Updated: 11/Nov/14  Resolved: 20/Aug/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4, 2.5
Fix Version/s: 2.4.3
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2310 Recent changes to DBAL SQL Server pla... Resolved
relates to DBAL-783 [GH-508] [DDC-2310] Fix evaluation of... Resolved

 Description   

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

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

Message:

Backport to 2.4 of https://github.com/doctrine/dbal/pull/508 required for https://github.com/doctrine/doctrine2/pull/925.



 Comments   
Comment by Doctrine Bot [ 20/Aug/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/f15c4823b1bc5fceacc199765709cb67001445b2

Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DBAL-922] [GH-617] deleted invalid target for quantifier Created: 11/Jun/14  Updated: 11/Nov/14  Resolved: 11/Jun/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

according to regexr.com the `?` quantifier is invalid in this context (see diff):
`/^(\s*SELECT\s+(?:((?>[^()])|(?:R)*)|[^(]))\sFROM\s/i`
http://www.regexr.com/

test query:
```
SELECT a.agreement_id, c.name as client, rp.name as roaming_partner, rp.active as active, te.name as technology, a.changedate as changedate, a.client_id as client_id, sv.value_text as status FROM rtd_agreement a, rtd_client c, rtd_client_user cu, rtd_user u, rtd_technology te, rtd_roaming_partner rp, rtd_agreement_state ast, rtd_state s, rtd_state_values sv WHERE (a.technology_id = te.technology_id) AND (a.roaming_partner_id = rp.roaming_partner_id) AND (a.client_id = c.client_id) AND (c.client_id = cu.client_id) AND (cu.user_id = u.user_id) AND (u.username = ?) AND (a.client_id IN ) AND (ast.agreement_id = a.agreement_id) AND (ast.state_id = s.state_id) AND (ast.state_id = sv.state_id) AND (ast.state_value = sv.state_value) AND (s.type = ?) AND (exists (select ast.agreement_id from rtd_agreement_state ast, rtd_state s where ast.agreement_id = a.agreement_id and ast.state_id = s.state_id and s.type = ? and ast.state_value = ?))
```

applying the current regex to this query results in `NULL`.
this only happens when i add a `(exists (select ...))` where-clause.
with the `?` quantifier removed, the regex works just fine.
please have a look at this.



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DBAL-800] [GH-522] Update DB2Platform.php to add ORDER BY data. Created: 30/Jan/14  Updated: 11/Nov/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

Added ORDER BY to doModifyLimitQuery in DB2Platform.php.



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DBAL-1045] [GH-727] Disallow empty delete criteria on the connection Created: 11/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
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/727

Message:

See #722

Ping @JeroenDeDauw @asm89



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Steve Müller [ 11/Nov/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/e35ce0486a1d161e739bed38fde27b7cc921f5f0





[DBAL-1044] [GH-726] MasterSlaveConnection::close() should reset connections array Created: 10/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: close, connection, master-slave


 Description   

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

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

Message:

When calling MasterSlaveConnection::close() the connections array should be restored to the default value.
Otherwise a subsequent call to the connect method will fire a PHP Notice because of undefined index in MasterSlaveConnection.php on line 165.



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DBAL-1042] [GH-724] Enable PostGIS extension for PostgreSQL tests Created: 10/Nov/14  Updated: 10/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

This is more like a proposal. Since PostGIS is one of the most popular extensions of PostgreSQL, it might be a good idea to enable it on Travis and make sure DBAL works with it.

At the moment, DBAL's Schema Tool does not work with PostGIS because it cannot handle some VIEWS added by PostGIS.

See: https://travis-ci.org/jsor/dbal/jobs/40528527



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DBAL-1030] [GH-713] Prevent result cache key collisions when sharing cache across different connections Created: 01/Nov/14  Updated: 10/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

There's an issue when using the default cache key generation for the result cache and using the same cache system across different connections as the generated key will be the same regardless of the connection used.

We can solve this just by using the connection params in the key generation. This issue is quite similar to the one fixed in 1075(https://github.com/doctrine/doctrine2/pull/1075).



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DBAL-1027] [GH-708] fix quoted sequence name Created: 27/Oct/14  Updated: 08/Nov/14  Resolved: 27/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-831 [GH-540] unit test to create constrai... Resolved

 Description   

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

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

Message:

@deeky666 we lost some fixes during the past days

https://github.com/deeky666/dbal/pull/1/files
https://github.com/deeky666/dbal/pull/2/files

This pull request is intending to bring back these fixes - THX



 Comments   
Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Steve Müller [ 27/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/a67db17b3d5bf373ba7a827db52dd0c7066cb08a

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DBAL-1040] [GH-722] Fix behaviour of Connection::delete when an empty array of criteria is provided Created: 07/Nov/14  Updated: 08/Nov/14  Resolved: 08/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: connection, delete


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 08/Nov/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DBAL-1039] [GH-721] Add @return type hint Created: 07/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: New Feature Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DBAL-1037] Type json_array is not consistent with NULL values Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Terje Bråten Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: JSON, dbal

Issue Links:
Duplicate
duplicates DBAL-1038 [GH-720] Type json_array is not consi... Open

 Description   

Fields of type json_array are created as "TEXT NOT NULL".
If you then try to store a NULL value in that field, the database will convert it to an empty string.
The "convertToPHPValue" method for that type only checks for NULL when it converts NULL to array(), it does not check for an empty string.

Either the field creation in the database must be changed to allow nulls, or the test must be changed to also test for the empty string.



 Comments   
Comment by Terje Bråten [ 07/Nov/14 ]

I created this ticket first, then a new one was automatically created when I submitted the pull request.

Please delete this ticket.

Comment by Marco Pivetta [ 07/Nov/14 ]

Terje Bråten marking it as duplicate is enough





[DBAL-1038] [GH-720] Type json_array is not consistent with NULL values Created: 06/Nov/14  Updated: 07/Nov/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: JSON, dbal

Issue Links:
Duplicate
is duplicated by DBAL-1037 Type json_array is not consistent wit... Resolved

 Description   

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

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

Message:

Fields of type json_array are often created as "TEXT NOT NULL", because they are not nullable by default.

If you have an existing table, and you add this field, all existing records will get an empty string as the value of the field and not NULL.
If you try to store a NULL value in that field, the database will convert it to an empty string.

The "convertToPHPValue" method for that type only checks for NULL when it converts NULL to array(), it does not check for an empty string.

The test must be changed to also test for the empty string, or else it behaves differently for when the column is set as nullable or not. And for the most common case, when the default vaule of letting the column be not nullable is used, this "feature" of converting blank values to empty arrays is not working.



 Comments   
Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DBAL-920] Use PDO::PGSQL_ATTR_DISABLE_PREPARES Created: 06/Jun/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Matteo Beccati Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: pgsql, prepared-statements
Environment:

PHP 5.6+, pdo_pgsql



 Description   

The new pgsql specific PDO attribute has been added in PHP 5.6+ to speed up queries that are going not going to be executed many times once prepared, by skipping the actual PQprepare round trip to the database.

The same goal can be achieved with PDO::ATTR_EMULATE_PREPARES, but that embeds the parameters in the queries which is not recommended.

For reference:
https://github.com/php/php-src/pull/619

I'll try to see if I have time to dig into doctrine2 and create a pull request, but I wanted to create a ticket before I forget






[DBAL-1036] [GH-719] Added TraceLogger to get backtrace for executed queries Created: 05/Nov/14  Updated: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Added a TraceLogger that returns a backtrace for the executed query.
The backtrace returns the last 10 frames, and it also formats the frames for easy reading






[DBAL-1035] [GH-718] implement method for retrying database queries/transactions Created: 05/Nov/14  Updated: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

It is best practice to implement retry logic for transactions that are aborted because of deadlocks or timeouts. This makes such method available inside the DBAL and also adds detection for errors where retrying makes sense in the different database drivers.

Deadlocks and timeouts are caused by lock contention and you often can design your application to reduce the likeliness that such an error occurs. But it's impossible to guarantee that such error conditions will never occur. This is why implementing retrying logic for such errors is actually a must when you have to ensure the application does not fail in edge cases or high load.
Some references where something similar has already been implemented:

I chose the name `retryable` because it is consistent with `transactional`. I think the implementation is quite straight forward and fits very well with the DBAL design.






[DBAL-1031] Oracle driver using portability does not use SQL logger Created: 03/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Bret R. Zaun Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

We are using the Oracle driver with some portability settings.
When trying to add a SQL logger to that connection no queries are being logged.
Having a quick look that the code I could not a place where the logger would be called in that scenario.

Am I missing something or has this just been left out ?

To give some more details here is the code we use to connect:

        $connectionParams = array(
                'dbname' => ...,
                'user' => ...,
                'password' => ...,
                'port' => ...,
                'driver' => 'oci8,
                'wrapperClass' => 'Doctrine\DBAL\Portability\Connection',
                'portability' => \Doctrine\DBAL\Portability\Connection::PORTABILITY_ALL,
                'fetch_case' => \PDO::CASE_LOWER
        );
        $configuration = new Doctrine\DBAL\Configuration();
        $logger = new Doctrine\DBAL\Logging\DebugStack();
        $configuration->setSQLLogger($logger);
        $this->conn = Doctrine\DBAL\DriverManager::getConnection($connectionParams, $configuration);


 Comments   
Comment by Marco Pivetta [ 05/Nov/14 ]

SQL Logging happens at connection level, therefore the issue is not related with the oracle setup itself. Please try verifying if there is any bug by using the EchoSQLLogger: https://github.com/doctrine/dbal/blob/6458b0bd6e62817e961a9611959a67b5f8622b59/lib/Doctrine/DBAL/Logging/EchoSQLLogger.php





[DBAL-1024] [GH-704] [DBAL-1024] Add more foreign key constraint violation error codes Created: 26/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: exceptions, pdoexception

Issue Links:
Dependency
depends on DBAL-1034 [GH-717] Fix tear down foreign key co... Resolved

 Description   

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

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

Message:

Driver exception conversion was missing some error codes for foreign key constraint violations. Currently only foreign key constraint violations for `DELETE` statements are tested. Foreign key constraint violations can also occur for `INSERT`, `UPDATE` and `TRUNCATE` write operations where some platforms provide dedicated error codes for.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1034] [GH-717] Fix tear down foreign key constraint violation exception tests Created: 05/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: tests, travis

Issue Links:
Dependency
is required for DBAL-1024 [GH-704] [DBAL-1024] Add more foreign... Resolved

 Description   

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

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

Message:

Fixes failing tests introduced in #704.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1029] [GH-712] Backporting a fix to allow connection without dbname Created: 31/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cascade, ddl, foreign-keys, sqlanywhere, sqlserver


 Description   

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

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

Message:

The fix is already in master at
https://github.com/doctrine/dbal/commit/387eb5457498781e24716286a2511f5d030d63fb
but because it has not been backported the functionnality is still broken
for symfony 2.5 for instance.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1032] [GH-715] Fix return type of Connection::project Created: 04/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: connection


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 04/Nov/14 ]

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

Comment by Doctrine Bot [ 04/Nov/14 ]

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





[DBAL-1028] [GH-709] [DBAL-1028] Fix fetching NULL values via fetchColumn() Created: 27/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: fetchcolumn, pdostatement, prepared-statements


 Description   

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

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

Message:

`PDO` drivers return `null` when retrieving a SQL `NULL` value from a column via `Statement::fetchColumn()`.
However all native driver implementations except `mysqli` return `false` which according to the interface should only be returned if no more rows are available or an error occurred. So currently it is not possible to retrieve a SQL `NULL` value via `Statement::fetchColumn()` with those drivers.
This PR fixes this. Additionally if a non-existing column index is requested from the resultset, `PDO` also returns `null` whereas those mentioned native drivers return `false`. This is also fixed.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1023] inconsistent line-ending Created: 24/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4.3
Fix Version/s: 2.5

Type: Improvement Priority: Trivial
Reporter: Dmitry Khlebnikov Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: coding-standards


 Description   

There are currently two files in the Git repository with DOS line endings. This is inconsistent with the rest of DBAL files in the repository and breaks Git when the DBAL repository is attached as a subtree to a project.

The files with DOS line endings are:

dbal/docs/design/AZURE_FEDERATIONS.md
dbal/tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL421Test.php



 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Patch provided in: https://github.com/doctrine/dbal/pull/706





[DBAL-1025] [GH-705] [DBAL-1025] Allow connecting without database name for sqlanywhere driver Created: 26/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: connection, sqlanywhere


 Description   

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

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

Message:

It should be possible to connect without a `dbname` connection parameter on capable platforms so that operations like `CREATE DATABASE` can be performed.
This PR removes the constraint for `sqlanywhere` driver and adds a functional test for capable platforms.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1021] [GH-702] [DBAL 930] Only introspect accessible schema objects in PostgreSQL Created: 23/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, postgresql, schema

Issue Links:
Reference
is referenced by DBAL-930 [GH-626] Update PostgreSqlPlatform.php Resolved

 Description   

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

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

Message:

Supersedes #626.

  • Rebased with master.
  • Adopted logic for `getListNamespacesSQL()` and `getListViewsSQL()`.

If anyone has an idea of how to test this, please let me know. Otherwise I would be fine without tests... :S



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-944] db2 alter column produces invalid sql syntax Created: 20/Jul/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: chris rehfeld Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: db2, ddl
Environment:

db2 v10.5 centos 6.5 64


Issue Links:
Reference
relates to DBAL-1019 [GH-701] [DBAL-944] Fix table column ... Resolved
is referenced by DBAL-945 [GH-633] Db2altercolumnsyntaxbug Resolved

 Description   

The "alter column" sql produced is always incorrect.

Example entity

Widget3.php
<?php
/**
 * @ORM\Entity
 **/
class Widget3
{
    /** @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue **/
    protected $id;

    /** @ORM\Column(type="string", length=20) **/
    private $str;
}

orm:schema-tool:create produces:
CREATE TABLE Widget3 (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, str VARCHAR(20) NOT NULL, PRIMARY KEY(id));

If you then change the entity like so:

Widget3.php
    /** @ORM\Column(type="string", length=100) **/
    private $str;
}

If you then run orm:schema-tool:update, it will try to run:

ALTER TABLE WIDGET3 ALTER STR str VARCHAR(100) NOT NULL;

which is invalid sql. It should be
ALTER TABLE WIDGET3 ALTER COLUMN STR SET DATA TYPE VARCHAR(100);

This renders the schema-tool inoperable in many scenarios, and causes a large portion of the db2 functional tests to fail.



 Comments   
Comment by chris rehfeld [ 20/Jul/14 ]

pull request https://github.com/doctrine/dbal/pull/633

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Marco Pivetta [ 05/Nov/14 ]

Fixed in DBAL-1019





[DBAL-1019] [GH-701] [DBAL-944] Fix table column alteration on DB2 Created: 22/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: db2, ddl

Issue Links:
Reference
relates to DBAL-945 [GH-633] Db2altercolumnsyntaxbug Resolved
is referenced by DBAL-944 db2 alter column produces invalid sql... Resolved

 Description   

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

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

Message:

Replacement for #633 as it was messed up, incomplete, untested and wrong.



 Comments   
Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-945] [GH-633] Db2altercolumnsyntaxbug Created: 20/Jul/14  Updated: 05/Nov/14  Resolved: 22/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: db2, ddl

Issue Links:
Reference
relates to DBAL-944 db2 alter column produces invalid sql... Resolved
is referenced by DBAL-1019 [GH-701] [DBAL-944] Fix table column ... Resolved

 Description   

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

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

Message:

fix for http://www.doctrine-project.org/jira/browse/DBAL-944



 Comments   
Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 05/Nov/14 ]

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





[DBAL-1033] [GH-716] Do not TRIM() parentheses around partial indexe conditions Created: 05/Nov/14  Updated: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Because PostgreSQL will return the expression with a lot of
parentheses we cannot TRIM() them easily. It is easier and more
correct to adapt to what PostgreSQL returns. That means the declaration
of partial indexes must be updated as follow:

Before:
``options=

{"where": "other_id IS NULL"}

``

After:
``options=

{"where": "(other_id IS NULL)"}

``

And fore more complexe conditions, that would be:
``options=

{"where": "(((id IS NOT NULL) AND (other_id IS NULL)) AND (name IS NULL))"}

``






[DBAL-942] [GH-632] Add test to verify null cast in boolean type Created: 18/Jul/14  Updated: 29/Oct/14  Resolved: 29/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This test verify how null values are casted to boolean values in PostgresPlatform.

NULL values are wrongly casted when flag *useBooleanTrueFalseStrings* is ```true```



 Comments   
Comment by Steve Müller [ 29/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/d12672808124e711c2cb78a82d4461ba2e89c7ef





[DBAL-1026] [GH-707] Dbal 831 Created: 27/Oct/14  Updated: 27/Oct/14  Resolved: 27/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 27/Oct/14 ]

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





[DBAL-831] [GH-540] unit test to create constraint on forced lowercase table in oracle Created: 04/Mar/14  Updated: 27/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-1027 [GH-708] fix quoted sequence name Resolved

 Description   

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

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

Message:

This might be crazy - but this was working in the 2.3.x code basis.

On master as well as 2.4.2 following error is throws:
````
Exception : [Doctrine\DBAL\Exception\TableNotFoundException] An exception occurred while executing 'DECLARE
constraints_Count NUMBER;
BEGIN
SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = '"OC_STORAGES"' AND CONSTRAINT_TYPE = 'P';
IF constraints_Count = 0 OR constraints_Count = '' THEN
EXECUTE IMMEDIATE 'ALTER TABLE "OC_STORAGES" ADD CONSTRAINT "OC_STORAGES_AI_PK" PRIMARY KEY ("NUMERIC_ID")';
END IF;
END;':

ORA-00942: table or view does not exist
ORA-06512: at line 6

With queries:
6. SQL: 'DECLARE
constraints_Count NUMBER;
BEGIN
SELECT COUNT(CONSTRAINT_NAME) INTO constraints_Count FROM USER_CONSTRAINTS WHERE TABLE_NAME = '"OC_STORAGES"' AND CONSTRAINT_TYPE = 'P';
IF constraints_Count = 0 OR constraints_Count = '' THEN
EXECUTE IMMEDIATE 'ALTER TABLE "OC_STORAGES" ADD CONSTRAINT "OC_STORAGES_AI_PK" PRIMARY KEY ("NUMERIC_ID")';
END IF;
END;' Params:
5. SQL: 'CREATE TABLE "oc_storages" ("id" VARCHAR2(64) NOT NULL, "numeric_id" NUMBER(10) NOT NULL, PRIMARY KEY("id"))' Params:
4. SQL: 'DROP TABLE "oc_storages"' Params:
3. SQL: 'DROP TRIGGER "OC_STORAGES"_AI_PK' Params:
2. SQL: 'ALTER SESSION SET NLS_TIME_FORMAT = 'HH24:MI:SS' NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS' NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH24:MI:SS' NLS_TIMESTAMP_TZ_FORMAT = 'YYYY-MM-DD HH24:MI:SS TZH:TZM' NLS_NUMERIC_CHARACTERS = '.,'' Params:

Trace:
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/DBALException.php:116
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Connection.php:988
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:971
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:429
/home/deepdiver/Development/ownCloud/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:569
/home/deepdiver/Development/ownCloud/dbal/tests/Doctrine/Tests/DBAL/Functional/Schema/OracleSchemaManagerTest.php:118

#0 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\Exception\TableNotFoundException))
#1 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest))
#3 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/Framework/TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 /home/deepdiver/Development/ownCloud/dbal/vendor/phpunit/phpunit/PHPUnit/TextUI/TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), '/::testConstrai...', Array, Array, false)
#6 /usr/share/php/PHPUnit/TextUI/Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 /tmp/ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 /tmp/ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9

{main}

````



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-941] [GH-631] updated PDO_SQLSRV connection to use driverOptions in prepare-function Created: 18/Jul/14  Updated: 26/Oct/14  Resolved: 26/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

it seems that the `PDO::prepare` `$driver_options` param was never used.
in order to use the `PDOStatement::rowCount` function, the connection to an sql-server has to be established with the following params:
```
$connectionParams = array(
'host' => $cfgHostName,
'port' => $cfgPort,
'dbname' => $cfgDatabase,
'user' => $cfgUser,
'password' => $cfgPassword,
'driver' => 'pdo_sqlsrv',
'driverOptions' => array(
PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL,
PDO::SQLSRV_ATTR_CURSOR_SCROLL_TYPE => PDO::SQLSRV_CURSOR_STATIC
)
);
```
the `driverOptions`-array is essential.
see http://msdn.microsoft.com/en-us/library/ff628176.aspx and http://at2.php.net/manual/de/pdo.prepare.php

with the follwing commit, the driver options are used by the PDO_SQLSRV prepared statements.
maybe there's a better way to implement this. please share your opinion on this fix.



 Comments   
Comment by Doctrine Bot [ 26/Oct/14 ]

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





[DBAL-879] Sequence default value [PGSQL] Created: 29/Apr/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mohammad Niknam Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: autoincrement, postgresql, sequence
Environment:

ArchLinux
PostgreSQL 9.3.4



 Description   

Hi
I'm using dbal to generate schmea from database via Schema-Manager. The problem is that my primary field 'id' have default value of 'nextval('test1_id_seq'::regclass)' but when I retrive columns using Doctrine\DBAL\Schema\AbstractSchemaManager::listTableDetails() or Doctrine\DBAL\Schema\Table::getColumns() , default value of the column 'id' is null.
In Doctrine\DBAL\Schema\PostgreSqlSchemaManager::_getPortableTableColumnDefinition() method at line 292 default value replaced with null, I don't know why but I guess It's because Driver compatibility.
Also Doctrine\DBAL\Schema\Sequence has no method to retrieve that table.
So I don't have the default value (pointing at sequence) and I can't find out what Sequence is linked to this table either.



 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Can you please provide a code example of how you create table + sequence and retrieve it?





[DBAL-918] [GH-614] Correcting the doc because mysqli doesn't support named parameter natively Created: 05/Jun/14  Updated: 26/Oct/14  Resolved: 26/Oct/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-915 emulate named parameters for statemen... Resolved

 Description   

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

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

Message:

The documentation incorrectly stated that their use was possible.



 Comments   
Comment by Doctrine Bot [ 27/Jun/14 ]

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

Comment by Steve Müller [ 26/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/568dc3c6f886be4e0f984c12109344fcb9be6bc1





[DBAL-903] php app/console doctrine:migration:diff generates redundant sql queries for postgres Created: 12/May/14  Updated: 26/Oct/14

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

Type: Bug Priority: Minor
Reporter: Hanov Ruslan Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

php app/console doctrine:migration:diff

generates redundant sql queries for postgres

symfony 2.4.2,
postgres 9.3
doctrine/orm: ~2.2,>=2.2.3
doctrine/doctrine-bundle: 1.2.*
doctrine/migrations: dev-master
doctrine/doctrine-migrations-bundle: dev-master

    public function up(Schema $schema)
    {
      
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql", "Migration can only be executed safely on 'postgresql'.");
        
        $this->addSql("DROP SEQUENCE acl_classes_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_security_identities_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_object_identities_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_entries_id_seq1 CASCADE");
    }

    public function down(Schema $schema)
    {
       
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql", "Migration can only be executed safely on 'postgresql'.");
        
        $this->addSql("CREATE SEQUENCE acl_classes_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_security_identities_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_object_identities_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_entries_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_classes_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_security_identities_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_object_identities_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_entries_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
    }


 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Doctrine ORM 2.2.x is EOL and won't receive any updates anymore. Please consider upgrading to at least 2.3 and reopen if the issue is still there. There have been a LOT of fixes to platforms' SQL generation since 2.2.x.
Also if you still encounter the issue, please add your mapping information, otherwise it will be hard to rack the issue down.

Comment by Steve Müller [ 26/Oct/14 ]

Oh sorry read your ORM version constraint wrong. Reopening. Please can you give the exact DBAL version you are using and mapping information? Thanks.





[DBAL-801] add SECOND, MINUTE, WEEK into DATE_SUB, DATE_ADD Created: 04/Feb/14  Updated: 26/Oct/14  Resolved: 26/Oct/14

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

Type: Improvement Priority: Minor
Reporter: gondo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

currently only HOUR, MONTH, YEAR options are implemented
would be nice to have all of them but for now at least the major one would be fine, so to complete the list, i would like to see:
SECOND, MINUTE, WEEK to be implemented

im not sure if all the platforms are capable of this, so if anyone can verify that would be great.
after that, implementation is simple copy/paste of existing code with very minor changes.



 Comments   
Comment by Steve Müller [ 24/Apr/14 ]

Patch supplied in PR: https://github.com/doctrine/dbal/pull/575

Comment by Doctrine Bot [ 16/May/14 ]

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

Comment by Steve Müller [ 26/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/d12eb786f3148e099e9cd14c76fba6c179a24629





[DBAL-375] Warning "Udefined index dbname" while creating database with oci8 driver Created: 31/Oct/12  Updated: 26/Oct/14  Resolved: 26/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2, 2.3.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pavel patrin Assignee: Steve Müller
Resolution: Invalid Votes: 1
Labels: dbname, oci8


 Description   

In config specified:

doctrine:
dbal:
driver: "oci8"
host: "localhost"
port: "1521"
dbname: "orcl50"
user: "SYSTEM"
password: "123456"
charset: UTF8

When i create database (with symfony 2, doctrine:database:create), got that error:

=====================================
Could not create database for connection named orcl50
Notice: Undefined index: dbname in /path/to/symfony/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/OCI8/Driver.php line 67
=====================================

If i comment "unset($params['dbname'])" in CreateDatabaseDoctrineCommand.php:54 all works fine.



 Comments   
Comment by Kris Willis [ 13/Nov/12 ]

I'm experiencing the same issue and your fix appears to work for me too; thanks!

Comment by Benjamin Eberlei [ 20/Apr/13 ]

on Oracle CREATE DATABASE is actually a CREATE USER. I am not sure the command should allow to do this.

Comment by Steve Müller [ 26/Oct/14 ]

This is not a DBAL issue, it has to be fixed in DoctrineBundle.





[DBAL-955] No exception thrown for query error Created: 31/Jul/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

SQL Server 2012



 Description   

Consider the following code:

IF OBJECT_ID('tempdb..#TestTable') IS NOT NULL DROP TABLE #TestTable

CREATE TABLE #TestTable
( 
id INT  NOT NULL IDENTITY(1,1) PRIMARY KEY, 
aDate DATETIME2(6) NULL
)

INSERT INTO #TestTable
(
aDate
) VALUES
(
'2014-07-30 08:54:23.000000'
)

SELECT *
FROM #TestTable
WHERE aDate > 2000

Error:

Msg 206, Level 16, State 2, Line 21
Operand type clash: datetime2 is incompatible with smallint

Problem: for this error no DBALexception is thrown

By the way, this does work (but does not affect problem description):

SELECT *
FROM #TestTable
WHERE aDate > '2000'


 Comments   
Comment by Marco Pivetta [ 31/Jul/14 ]

Flip your code example includes no DBAL code: could you also add the PHP wrapping around those SQL statements?

Comment by Steve Müller [ 26/Oct/14 ]

Flip ping.





[DBAL-932] [GH-627] Fix escaping of column name for specific alter table case Created: 01/Jul/14  Updated: 26/Oct/14  Resolved: 26/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

When changing the length of a field, the column name needs to be escaped
properly.

Happens for example when changing the length of a column called "User" on a table.



 Comments   
Comment by Doctrine Bot [ 22/Jul/14 ]

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

Comment by Steve Müller [ 26/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/a43e8da1e821de1cc6e636ebc2c44f0d9dae5c9a





[DBAL-753] Evaluate owncloud patch for Oracle quoting Created: 31/Dec/13  Updated: 26/Oct/14  Resolved: 26/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1016 [GH-700] [DBAL-1016] Fix explicitly q... Resolved

 Description   

See https://github.com/owncloud/3rdparty/commit/7ae81563894b971e51cee7bdb0ac2da83ecc5149



 Comments   
Comment by Steve Müller [ 01/Jan/14 ]

There are already several open tickets concerning general quotation issues. The patch might solve a little subset of the root problem which is actually really tricky. We need a more general and robust approach that works on all platforms.
See DBAL-96

Comment by Steve Müller [ 26/Oct/14 ]

Fixed by DBAL-1016





[DBAL-1016] [GH-700] [DBAL-1016] Fix explicitly quoted table identifiers in ALTER TABLE statements Created: 20/Oct/14  Updated: 26/Oct/14  Resolved: 21/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, quoting, schemadiff, schematool

Issue Links:
Reference
is referenced by DBAL-753 Evaluate owncloud patch for Oracle qu... Resolved

 Description   

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

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

Message:

Another improvement to the neverending quotation issues.
This patch fixes explicitly quoted table identifiers in `ALTER TABLE` statements.
Additionally some minor fixes had to be applied such as misc fixing of foreign key constraint statements order in the sequence of statements necessary to alter a table.



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1000] MySQL DB cannot be created from Cli, returns "QLSTATE[42000] [1049] Unknown database" Created: 14/Oct/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Marcus Malka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, mysql

Attachments: PNG File Screen Shot 2014-10-14 at 10.53.44.png    

 Description   

When trying to create a database via Symfony (tested 2.3, 2.4, 2.5) console using Doctrine, if returns

[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[42000] [1049] Unknown database 'livedb_ci_tco_dev'

This effectively prevents re-creating the database.

I traced the error, it seems database existence is either not checked or not functioning, and it tries to connect to the DB, resulting in an exception. In older versions the trace seemed like it checked if DB exists, and didn't try to connect.

I tested some different commit versions to assess where the bug was introduced - here is my brief list of working/non-working versions.

812dd9d (v.2.5.0-BETA3) fail
61eb1ee fail
3176f51 fail
da43b76 works
ce3a56e works
594e326 works
ba9aa63 (v.2.5.0-BETA2) works

So looking from the commit graph, to me it seems like it might have been introduced in commit 3176f51



 Comments   
Comment by Marco Pivetta [ 14/Oct/14 ]

Marcus Malka are you sure that you are running the correct command? If the DB is not there, I would expect an exception.

Comment by Christophe Coevoet [ 14/Oct/14 ]

Marco Pivetta This command is precisely about creating the database when it does not exist yet. I think this failure is related to the guessing of the platform version in DBAL 2.5, which will require connecting to the DB early.

Comment by Marco Pivetta [ 14/Oct/14 ]

Christophe Coevoet the screenshot shows the `drop` command being used

Comment by Marcus Malka [ 14/Oct/14 ]

I tested with multiple commands, mainly drop and create were most common.

The difference is in the error that gets produced with the different commits applied - other one gives the "The database is not there" kind of error you would expect. The other version gives an "can't do the operation because I can't connect to the database" even when you try to create it, and gives a similar "can't drop the database because I can't connect to the database" kind of error, which still says it tries to do something weird. My screenshot could've been taken from the create-command too, the error was identical.

I should have a breaking composer.json file in my version control on another machine. I'll try to add that later to facilitate debugging.

Comment by Steve Müller [ 14/Oct/14 ]

Christophe Coevoet you are right, that DBAL now connects early if you request the database platform but that should not be an issue as you may not specify a non-existing database name when connecting to creating a new database, anyways. And as far as I can see the CreateDatabaseDoctrineCommand even explicitly unsets the database name in the connection params here: https://github.com/doctrine/DoctrineBundle/blob/master/Command/CreateDatabaseDoctrineCommand.php#L71-L80 for a "temporary" connection.
Dropping a database still should require the database to be existent so connecting to it before dropping should be fine or am I missing something here?

Comment by Marcus Malka [ 15/Oct/14 ]

@Steve Muller - is it tries to create the connection and creates an error also when the database is not supposed to be there, for ex. in create action. Effectively breaking createDatabase command.

When I traced the code, it seemed to go in to the platform version checking, and seemed like it just didn't realize early enough that the DB isn't there (that was my guess - I don't know doctrine internals well enough to say if that's how it's planned to work or not).

Comment by Benjamin Eberlei [ 26/Oct/14 ]

This is an issue in DoctrineBundle that only appears in combination with DBAL 2.5.

The problem is Symfony apparently connects to the database in "Container::get" of the connection already. That has to be fixed.





[DBAL-551] [GH-340] Added driver map getter Created: 25/Jun/13  Updated: 24/Oct/14  Resolved: 10/Aug/13

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

We can think of several situations where a read access to the supported drivers is required. I personnaly need it in the following use cases :

  • Validating a driver choice in a mutli-platform application installer
  • Generating migration classes for all the available platforms

This PR just adds a getter for that list. As it is a harmless and non-BC-break change, it would be great if it could be merged also into the 2.3 version.



 Comments   
Comment by Doctrine Bot [ 10/Aug/13 ]

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

Comment by Doctrine Bot [ 24/Oct/14 ]

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





[DBAL-1022] [GH-703] [DBAL-1022] Wrap PDOException in PDOConnection::exec() Created: 23/Oct/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: connection, pdostatement


 Description   

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

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

Message:

Seems we forgot to wrap `\PDOException` in `PDOConnection::exec()` therefore calls like `PDOConnection::exec('DROP TABLE foo')` are not properly converted to `TableNotFoundException` accordingly. (or similar).



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-930] [GH-626] Update PostgreSqlPlatform.php Created: 29/Jun/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: ddl, postgresql, schema

Issue Links:
Reference
relates to DBAL-1021 [GH-702] [DBAL 930] Only introspect a... Resolved

 Description   

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

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

Message:

If the database have different schemes, with objects, that the actual logged in user has no rights, the existing statements will collect all objects (sequences and tables) and try to read them in later steps. This will throws exceptions. The reason for that is the fact, that both procedures getListSequencesList() and getListTablesSQL() will receive all known database objects from postgres catalogs. But the actual logged-in user, maby has no read permissions to object inside other scheme-owner. The additional parts inside both sql-statements will reduce the result to only objects that the user are able to see.



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-992] [GH-680] Enabled placeholders for "in" method in ExpressionBuilder Created: 18/Sep/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: in, parameters, querybuilder


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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

Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-940] ORDER BY with LIMIT in SQL Server does not work correctly Created: 17/Jul/14  Updated: 23/Oct/14  Resolved: 23/Oct/14

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

Type: Bug Priority: Major
Reporter: M.K. Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: limit, offset, orderBy, sqlsrv
Environment:

SQL Server


Issue Links:
Reference
relates to DBAL-927 [GH-622] improved sqlserver 'doModify... Resolved

 Description   

The function doModifyLimitQuery() in Doctrine\DBAL\Platforms\SQLServerPlatform does work correctly.

It removes the user generated ORDER BY (gets moved to OVER clause), but does not apply an ORDER BY on the row number created with ROW_NUMBER().

$orderBy = stristr($query, 'ORDER BY');

//Remove ORDER BY from $query (including nested parentheses in order by list).
$query = preg_replace('/\s+ORDER\s+BY\s+([^()]+|\((?:(?:(?>[^()]+)|(?R))*)\))+/i', '', $query);

$format  = 'SELECT * FROM (%s) AS doctrine_tbl WHERE doctrine_rownum BETWEEN %d AND %d';

The last format string should be:

$format  = 'SELECT * FROM (%s) AS doctrine_tbl WHERE doctrine_rownum BETWEEN %d AND %d ORDER BY doctrine_rownum';


 Comments   
Comment by Marco Pivetta [ 17/Jul/14 ]

Possible relation with DBAL-927

Comment by Steve Müller [ 23/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/040d49c16a737d1349ae86443d64b3382cf4ce5d





[DBAL-965] [GH-654] doModifyLimitQuery() was missing an outer "ORDER BY doctrine_rownum" Created: 06/Aug/14  Updated: 23/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Refer to:
http://www.doctrine-project.org/jira/browse/DBAL-940



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-1020] Postgres and using Schema tool throws cardinality errors Created: 22/Oct/14  Updated: 23/Oct/14

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Dominic Watson Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: ddl, postgresql

Attachments: PNG File 6ZeW_jJFUbOCx5uGJ2feANtAsZOr72zhDL4szJ6p5VE.png     File pg_catalog_pg_class.csv    

 Description   

Postgres: 9.3.5.0 (Postgres App for OSX) w/ PostGIS extensions
doctrine/common: 2.4.x-dev ae92d076442e27b6910dd86a1292a8867cf5cfe4
doctrine/dbal: dev-master 1c9c24a7e2295b71249ae2a719ce38861fccd551
creof/doctrine2-spatial: https://github.com/intellix/doctrine2-spatial 4023ca8fbe703043012c31d6df26b9bc7b0a972d

It seems every now and again when I come to use the schema-tool I'm getting exceptions which can only be fixed by dropping the database and recreating from scratch.

The following SQL looks to be generated here: \Doctrine\DBAL\Platforms\AbstractPlatform::getListTableForeignKeysSQL

SELECT quote_ident(r.conname) as conname, pg_catalog.pg_get_constraintdef(r.oid, true) as condef
                  FROM pg_catalog.pg_constraint r
                  WHERE r.conrelid =
                  (
                      SELECT c.oid
                      FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n
                      WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"',user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace
                  )
                  AND r.contype = 'f'

The full stack trace is as follows:

 ---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~--
  Dropping database schema...
      ./bin/doctrine-module orm:schema-tool:drop --force --verbose
---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~--
Dropping database schema...


                                                                                                                                                                                                       
  [Doctrine\DBAL\Exception\DriverException]                                                                                                                                                            
  An exception occurred while executing 'SELECT quote_ident(r.conname) as conname, pg_catalog.pg_get_constraintdef(r.oid, true) as condef                                                              
                    FROM pg_catalog.pg_constraint r                                                                                                                                                    
                    WHERE r.conrelid =                                                                                                                                                                 
                    (                                                                                                                                                                                  
                        SELECT c.oid                                                                                                                                                                   
                        FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n                                                                                                                          
                        WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"'  
  ,user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace                                                                                              
                    )                                                                                                                                                                                  
                    AND r.contype = 'f'':                                                                                                                                                              
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression                                                                                     
                                                                                                                                                                                                       


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractPostgreSQLDriver.php:82
 Doctrine\DBAL\Driver\AbstractPostgreSQLDriver->convertException() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:116
 Doctrine\DBAL\DBALException::driverExceptionDuringQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:833
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4




                                                                                                                    
  [Doctrine\DBAL\Driver\PDOException]                                                                               
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression  
                                                                                                                    


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:94
 Doctrine\DBAL\Driver\PDOConnection->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:830
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4




                                                                                                                    
  [PDOException]                                                                                                    
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression  
                                                                                                                    


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:92
 PDO->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:92
 Doctrine\DBAL\Driver\PDOConnection->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:830
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4


orm:schema-tool:drop [--dump-sql] [-f|--force] [--full-database]


 Comments   
Comment by Marco Pivetta [ 22/Oct/14 ]

What are the contents of pg_catalog.pg_class ?

Comment by Dominic Watson [ 22/Oct/14 ]

Uploaded CSV of that table

Comment by Dominic Watson [ 22/Oct/14 ]

After running the subquery as suggested in IRC:

  SELECT c.oid                                                                                                                                                                   
                        FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n                                                                                                                          
                        WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"'  
  ,user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace  

oid
-------
40152
39687

Comment by Marco Pivetta [ 22/Oct/14 ]

Can you run the query:

SELECT
    c.*
FROM
   pg_catalog.pg_class c, pg_catalog.pg_namespace n
WHERE
    n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast')
    AND c.relname = 'state'
    AND n.nspname = ANY(string_to_array((
        select replace(replace(setting,'"$user"', user), ' ', '')
        from pg_catalog.pg_settings
        where name = 'search_path'
    ),','))
    AND n.oid = c.relnamespace
Comment by Dominic Watson [ 22/Oct/14 ]
  relname varchar,
  relnamespace oid,
  reltype oid,
  reloftype oid,
  relowner oid,
  relam oid,
  relfilenode oid,
  reltablespace oid,
  relpages int,
  reltuples real,
  relallvisible int,
  reltoastrelid oid,
  reltoastidxid oid,
  relhasindex bool,
  relisshared bool,
  relpersistence char(1),
  relkind char(1),
  relnatts smallint,
  relchecks smallint,
  relhasoids bool,
  relhaspkey bool,
  relhasrules bool,
  relhastriggers bool,
  relhassubclass bool,
  relispopulated bool,
  relfrozenxid xid,
  relminmxid xid,
  relacl _aclitem,
  reloptions _text

state,2200,40154,0,10,0,40152,0,0,0,0,0,0,true,false,p,r,2,0,false,true,false,true,false,true,6694,1,NULL,NULL
state,39587,39689,0,10,0,39687,0,0,0,0,39694,0,true,false,p,r,15,3,false,true,false,false,false,true,6629,1,NULL,NULL
Comment by Dominic Watson [ 22/Oct/14 ]

My ZF2 onBootstrap as well, in case it changes anything:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
<?php
namespace Flatscanner;

use Doctrine\ORM\Mapping\UnderscoreNamingStrategy;
use ZF\Apigility\Provider\ApigilityProviderInterface;
use Zend\Uri\UriFactory;
use Doctrine\DBAL\Types\Type;

class Module implements ApigilityProviderInterface
{
    public function getConfig()
    {
        return include __DIR__ . '/../../config/module.config.php';
    }

    public function onBootstrap($e)
    {
        Type::addType('geometry', 'CrEOF\Spatial\DBAL\Types\GeometryType');
        Type::addType('point', 'CrEOF\Spatial\DBAL\Types\Geometry\PointType');
        UriFactory::registerScheme('chrome-extension', 'Zend\Uri\Uri');

        // Set naming strategy
        $em = $e->getTarget()->getServiceManager()->get('doctrine.entitymanager.orm_default');
        $em->getConnection()->getDatabasePlatform()->registerDoctrineTypeMapping("_text", "text"); // assuming it is a text LOB
        $em->getConfiguration()->setNamingStrategy(new UnderscoreNamingStrategy(CASE_LOWER));
    }

    public function getAutoloaderConfig()
    {
        return array(
            'ZF\Apigility\Autoloader' => array(
                'namespaces' => array(
                    __NAMESPACE__ => __DIR__,
                ),
            ),
        );
    }
}
Comment by Steve Müller [ 23/Oct/14 ]

Most probably also affects 2.4 as the codebase has not changed at the critical places. Possibly 2.3 is also affected by this. Could need a check.





[DBAL-1004] [GH-689] [DBAL-1004] Fix generating COMMENT ON COLUMN statements for quoted identifiers Created: 15/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: comments, ddl


 Description   

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

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

Message:

Fixes SQL generation for `COMMENT ON COLUMN` statements on all platforms.
See also: https://github.com/doctrine/dbal/pull/687#issuecomment-59203122



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DBAL-1003] [GH-688] Fixed closing a connection Created: 14/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: connection

Issue Links:
Dependency
depends on DBAL-1008 [GH-691] Add test case for #688 Resolved
is required for DBAL-997 [GH-685] Update MasterSlaveConnection... Resolved

 Description   

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

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

Message:

The inner connection should be unreferenced, but the property should not be removed from the object

Refs https://github.com/doctrine/dbal/pull/685



 Comments   
Comment by Doctrine Bot [ 14/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DBAL-1008] [GH-691] Add test case for #688 Created: 16/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: connection

Issue Links:
Dependency
is required for DBAL-997 [GH-685] Update MasterSlaveConnection... Resolved
is required for DBAL-1003 [GH-688] Fixed closing a connection Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DBAL-997] [GH-685] Update MasterSlaveConnection.php Created: 06/Oct/14  Updated: 22/Oct/14  Resolved: 14/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Dependency
depends on DBAL-1003 [GH-688] Fixed closing a connection Resolved
depends on DBAL-1008 [GH-691] Add test case for #688 Resolved

 Description   

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

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

Message:

If you use close method just before connect method, $this->_conn is unset and we have got an error php.



 Comments   
Comment by Doctrine Bot [ 06/Oct/14 ]

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

Comment by Doctrine Bot [ 14/Oct/14 ]

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

Comment by Marco Pivetta [ 14/Oct/14 ]

Incorrect fix, as it fixes a symptom rather than the issue itself





[DBAL-1017] Altering a foreign key column is not done properly for MySQL Created: 21/Oct/14  Updated: 21/Oct/14

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5, 2.4.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, schematool


 Description   

Altering a foreign key column column (for instance to make it not-nullable) or the index of a foreign key does not work on MySQL (to be exact, it does not work on some MySQL setups, but I haven't found the config setting impacting it yet). Making it work requires dropping the foreign key before altering the column/index and readding it after



 Comments   
Comment by Steve Müller [ 21/Oct/14 ]

Christophe Coevoet DBAL-732 related?





[DBAL-796] [GH-518] support to ibmi db2 - as400 Created: 22/Jan/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: as400, db2, ibmi


 Description   

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

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

Message:

support for ibmi db2 (as400)
some code in DB2Platform doesn't yet work on ibmi db2



 Comments   
Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-1015] [GH-699] Adds support for setting the charset in SQLSrv Created: 20/Oct/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: charset, dsn, encoding, mssql, sqlserver


 Description   

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

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

Message:

As seen here => http://technet.microsoft.com/en-us/library/cc626307(v=sql.105).aspx



 Comments   
Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DBAL-993] TimeType should reset date fields to UNIX epoch Created: 26/Sep/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4.3, 2.3.5
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Pavel Horal Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: datetime, type

Issue Links:
Reference
relates to DDC-179 Time part of Date fields is initializ... Resolved

 Description   

What is the issue

This issue is similar to DDC-179 . The problem is that when working with time field types that the value is parsed with the current date. Special '!' format prefix or '|' format suffix should be used to reset date fields to UNIX epoch.

Why is it issue

Resetting fields to a well defined value will allow correct time-based \DateTime comparisons, which is not possible in the current implementation (at least not without hacks).

We came across this behaviour when working with Symfony2 forms. Symfony2 form components are using '|' (pipe) format suffix when parsing time fields. This generates incorrect change-sets on data layer.



 Comments   
Comment by Steve Müller [ 26/Sep/14 ]

I don't get the issue here. It was already patched in DDC-179, no? See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DateType.php#L65
If I am missing something here, can you please give more details or provide an example of your use case?

Comment by Pavel Horal [ 26/Sep/14 ]

I am talking about https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/TimeType.php#L65 . So it is pretty much the same as DDC-179, but just a different temporal type.

Comment by Steve Müller [ 26/Sep/14 ]

I guess I understand. So you would expect the date part to be resetted to UNIX epoch, right? Like:

$time = '08:59:44';

$timeType->convertToPHPValue($time, $platform); // returns a \DateTime object of '1970-01-01 08:59:44'
Comment by Pavel Horal [ 26/Sep/14 ]

Exactly.

The current behavior feels incorrect, because if you have two entries in the DB both set to 06:00:00 and you will parse one at 2014-09-26T23:59:59.999 and the second one at 2014-09-27T00:00:00.000 they will be parsed to a different timestamps.
Also as I have mentioned the current behaviour don't play nice with Symfony2's date and time form fields (https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/DataTransformer/DateTimeToArrayTransformer.php#L176), which always resets unparsed fields to UNIX epoch.
And at last the current behavior is a bit inconsistent with date handling introduced in DDC-179.

Comment by Marco Pivetta [ 19/Oct/14 ]

Needs test case + patch: Pavel Horal can you provide a PR for this issue?

Comment by Pavel Horal [ 19/Oct/14 ]

Created https://github.com/doctrine/dbal/pull/697 .

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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





[DBAL-1014] [GH-698] [DBAL-1014] Support HHVM mysqli driver Created: 20/Oct/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: hhvm, mysqli


 Description   

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

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

Message:

Adds support for HHVM's mysqli driver implementation.



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

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





[DBAL-872] [GH-570] Add support for out cursor in OCI8 Created: 18/Apr/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5, 2.4.3
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: cursor, oracle


 Description   

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

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

Message:

I don't know if it is the best solution, but it's a beginning.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Marco Pivetta [ 19/Oct/14 ]

See discussion on github for more details: can't implement a feature that is adapter-specific and has no abstraction layer on top.





[DBAL-978] [GH-665] convenience method for FULL OUTER JOINs in QueryBuilder Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

was working on a project today where I needed a full outer join and found out that the method was missing in the QueryBuilder.
It's a minor change and I have also included a test case.

david



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-923] [GH-618] sqlite does not support bigint Created: 12/Jun/14  Updated: 19/Oct/14  Resolved: 23/Jun/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-979 [GH-666] [DBAL-924] Fix SQLite intege... Resolved

 Description   

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

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

Message:

BIGINT should be falling back to integer for SQLite



 Comments   
Comment by Doctrine Bot [ 16/Jun/14 ]

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

Comment by Steve Müller [ 23/Jun/14 ]

Reopened in: https://github.com/doctrine/dbal/pull/619

Comment by Doctrine Bot [ 04/Jul/14 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-924] [GH-619] fix all sqlite integer types Created: 16/Jun/14  Updated: 19/Oct/14  Resolved: 21/Aug/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-979 [GH-666] [DBAL-924] Fix SQLite intege... Resolved

 Description   

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

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

Message:

The SQLite platform introduced integer types that are not supported. This PR addresses integer issues with SQLite



 Comments   
Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-979] [GH-666] [DBAL-924] Fix SQLite integer type primary autoincrement columns Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 21/Aug/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.5
Security Level: All

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

Issue Links:
Duplicate
duplicates DBAL-923 [GH-618] sqlite does not support bigint Resolved
duplicates DBAL-924 [GH-619] fix all sqlite integer types Resolved

 Description   

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

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

Message:

This is a followup PR for https://github.com/doctrine/dbal/pull/618 and https://github.com/doctrine/dbal/pull/619.
It provides a compromise between PK autoincrement column declaration and differenciation of different integer types.
Each integer type column that is declared as an autoincrement column will fallback to `INTEGER` SQL declaration while keeping the possibility to create non-autoincrement columns for each integer type.
There should also be no comparator issues left with this PR generating useless SQL diffs.



 Comments   
Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/b6cd3238b4a71f755b9e3a80f39d5551910b73a6

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-947] [GH-634] Transaction object definition Created: 21/Jul/14  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-2279 [GH-571] Update lib/Doctrine/ORM/Enti... Resolved

 Description   

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

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

Message:

To move forward with the Transaction Object, here is an alternative proposal to #571.

This keeps the same basic idea, but now `createTransaction()` returns a `TransactionDefinition` object, which is configurable, and has a `begin()` method that starts the underlying transaction and returns the `Transaction` object:

$tx = $em->createTransaction() // TransactionDefinition
->withIsolationLevel(Connection::TRANSACTION_SERIALIZABLE) // TransactionDefinition
->begin(); // Transaction

I think that this implementation checks all the boxes:

  • Clear separation between the Transaction and its Definition
  • Once the Transaction is created, its Definition is set and cannot be changed
  • No risk to forget to call `begin()`: if you do, you'll deal with a TransactionDefinition and just get a call to undefined method if you try to `commit()` it. Plus, your IDE will be able to warn you while coding.

And needless to say, we're still keeping 100% BC compatibility.

What do you think?






[DBAL-919] [GH-615] Add sanitization for IN() expressions Created: 05/Jun/14  Updated: 19/Oct/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

The current IN() expression is vulnerable to SQL injection and should be sanitized. It should be noted that the default is set to string because this works for all types including numeric values. However, this method can be slow for large lists. A recent test of 8,000 values too about .38 seconds. Numeric values only take about .015 seconds for the same data set.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-982] [GH-669] Correct schema generation for altering PostgreSQL sequences Created: 25/Aug/14  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

I wrote a detailed explanation here so it is hopefully easy to follow:

        1. Background

With PostgreSQL there are three states for a column to receive a sequence generator: no generator, an internal shortcut towards generating an auto incrementing sequence (SERIAL), and a manually-created sequence. In its current state, DBAL accepts only a boolean "autoincrement" to its `getAlterTableSql()` method (via the passed-in `TableDiff`).

This results in the following scenario:

  • ORM maps a column to "AUTO" which is treated as a sequence (autoincrement = false)
  • DBAL `PostgreSqlSchemaManager` inspects existing table and notices a sequence (autoincrement = true)
  • Diff logic in `getAlterTableSql()` will always detect that autoincrement has changed, and that the requested value is false, so it will always issue a `DROP DEFAULT` statement

This is clearly a bug, and can be proved via a unit test; run the `AbstractPostgreSqlPlatformTestCase::testAlterSchemaSequenceToSequence` test that I have committed against the current DBAL code and you will see it fail (based on what is currently passed in via the ORM; see Q&A below for detailed explanation).

        1. Solution

There already existed a few references to a not-yet-implemented `sequence` property of a column definition, which would store the name of the sequence being used on the column. This makes sense and allows us to support all three column states with regards to sequence, while also preserving backwards compatibility. The default is always null, so it will result in no changes to functionality on other platforms.

So, this PR:

  • Adds the `Column::_sequence` property
  • Correctly sets that property during the `PostgreSqlSchemaManager::_getPortableTableColumnDefinition` method (it actually was already there, just not being used)
  • Checks the value during the `Comparator::diffColumn` operation
  • Uses the value to more correctly determine when to create/drop a sequence during a schema alter
  • Adds the appropriate unit tests to verify the six different combinations here
        1. Q&A

Is this just an ORM bug? Could the ORM be changed to just set autoincrement = true for the AUTO and SEQUENCE strategies?

This would solve the immediate problem, yes. However, it would leave no possible distinction between the three ORM mapping strategies of AUTO, SEQUENCE, and IDENTITY. Further, it would cause a break in `getAlterTableSql()` because setting autoincrement to true implies that we are using the database-generated identity sequence which has a specific name, thereby removing the ability for a user to define a sequence manually with a custom name and have it be used here. This strategy opens the door for addressing those cases later, and does not cause a BC break today.

This seems incomplete; for example, this still doesn't handle the case where a sequence is requested to change from AUTO to a specifically-named sequence.

That is intentional. I think these other cases could and probably should be handled, but they would require changes to both the DBAL and ORM. For example, we pass a `Sequence` object to the create/alter/drop sequence functions, but we do not pass one to the alter function. As a result, the actual sequence name is not available here, so we would absolutely need to make a more thought-out ORM change to solve this. I think that should be separate work, or it could just be something we do not support.

Won't this still require an ORM change to set the `sequence` property?

Yes, the following needs to be added to the `SchemaTool::gatherColumn` method:

```php
if ($class->isIdGeneratorSequence() && $class->getIdentifierFieldNames() == array($mapping['fieldName']))

{ $options['sequence'] = $class->sequenceGeneratorDefinition['sequenceName']; }

```

However, even without that change, this solves the problem on the DBAL side and opens the door to fixing the ORM to behave correctly here.

How do things behave today and how do we want them to behave with respect to alters?

This is what should happen in each alter scenario:

Existing State Mapped to AUTO or SEQUENCE Mapped to IDENTITY (Auto Increment) Regular Column
-------------- ----------------------- ----------------------------------- --------------
*No Sequence* Add Sequence; Default to `nextval(seqeuence)` Add Serial (Identity Sequence) No Change
*Default `nextval(seqeuence)`* No Change No Change Drop Default

This is what does happen today:

Existing State Mapped to AUTO or SEQUENCE Mapped to IDENTITY (Auto Increment) Regular Column
-------------- ----------------------- ----------------------------------- --------------
*No Sequence* No Change (Bad) Add Serial (Identity Sequence) No Change
*Default `nextval(seqeuence)`* Drop Default (Bad) No Change Drop Default


 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-984] [GH-671] Fix quoted integers as default value. Created: 28/Aug/14  Updated: 19/Oct/14  Resolved: 29/Aug/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The comparison names for the bigint and smallint types in the sql declaration for default values are misspelled and the values are returned quoted unlike the integer type that is returned unquoted.



 Comments   
Comment by Doctrine Bot [ 29/Aug/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/60a19586699e9e6ab734c810103ae4294f2ab77f

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-609] [GH-373] HHVM compatibility: implement declared interfaces Created: 15/Sep/13  Updated: 19/Oct/14  Resolved: 13/Dec/13

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

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


 Description   

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

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

Message:

HHVM does not allow declaration of interface implementation without real implementation of methods which parameters differs from parent class.



 Comments   
Comment by Doctrine Bot [ 13/Dec/13 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-999] Get a Sql Server error on Order By - Symfony2 Created: 08/Oct/14  Updated: 19/Oct/14

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Maël SOURISSEAU Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orderBy, query, sqlserver


 Description   

Using Symfony with Sql Server and from what I've read, it seems that the connection to the database is not stable.

As soon as I use the orderBy method I get an error :

Here's an example :

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
  $qStores =
        $this->getManager()
             ->createQueryBuilder()
             ->select('rpdv')
             ->from('MainBundle:PointDeVenteReference', 'rpdv')
             ->andWhere( 'rpdv.partenaireClient = :id_partner ' )
                 ->setParameter( 'id_partner', $this->getUser()->getPartenaire()->getIdPartenaire() )
             ->orderBy( 'rpdv.idPointDeVenteReference' , 'DESC' )
             ->setFirstResult( 0 )
             ->setMaxResults( 30 );

And the error :

An exception has been thrown during the rendering of a template ("An exception occurred while executing
'SELECT DISTINCT TOP 30 id_point_de_vente_reference0
FROM ( SELECT p0_.id_point_de_vente_reference AS id_point_de_vente_reference0,
p0_.reference AS reference1,
p0_.date_derniere_modification AS date_derniere_modification2,
p0_.blocage AS blocage3
FROM point_de_vente_reference p0_
WHERE p0_.id_partenaire_client = ?
ORDER BY p0_.id_point_de_vente_reference DESC ) dctrn_result
ORDER BY id_point_de_vente_reference0 DESC'
with params [2829]:SQLSTATE[42000]:
[Microsoft][SQL Server Native Client 11.0][SQL Server]
The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions,
unless TOP, OFFSET or FOR XML is also specified.") in MainBundle:Default:store/list.html.twig at line 79.
I tried to change the class SQLServerPlatform with corrections found on the net, without success.

Do you have any idea?

Thx !



 Comments   
Comment by Steve Müller [ 08/Oct/14 ]

Which version of DBAL are you using? A lot of fixes have been applied to SQL Server's LIMIT/OFFSET query rewriting in DBAL during the last months.

Comment by Maël SOURISSEAU [ 08/Oct/14 ]

2.4 for DBAL.

Under my request, I have :

$stores = new Paginator( $qStores, TRUE );

In passing the second parameter to FALSE, I have no error.

Comment by Marco Pivetta [ 19/Oct/14 ]

I'd suggest checking ORM+DBAL latest to see if the issue still exists, as those component have suffered from radical changes in the last few months.





[DBAL-1013] [GH-696] [DBAL-1013] Fix table diff's new name if it is not set Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, schematool


 Description   

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

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

Message:

The `TableDiff` should not wrap `TableDiff::$newName` into an `Identifier` if it is not set.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1012] [GH-695] [Documentation] Add missing quotes at the end of literal strings Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 17/Oct/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, documentation


 Description   

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

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



 Comments   
Comment by Steve Müller [ 17/Oct/14 ]

Fixed as of https://github.com/doctrine/dbal/commit/d400586168bfc19b8fe84d7cf9f432b54ce21306

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1009] [GH-692] [DBAL-1009] Fix column comment lifecycle Created: 16/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: comments, ddl, schematool


 Description   

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

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

Message:

The lifecycle of a column comment is not correct.
The comparator would not detect added comments. Also platforms did not handle the licecycle consistently.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1001] NULL / NOT NULL clause always appended to column alteration declaration in Oracle Created: 14/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.5
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Steve Müller Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, oracle, schematool

Issue Links:
Dependency
depends on DBAL-1002 [GH-687] [DBAL-1001] Fix NULL / NOT N... Resolved
Reference
relates to DBAL-472 Oracle schema modification - incorrec... Resolved

 Description   

Due to commit https://github.com/doctrine/dbal/commit/0782e9251a1df353ba589d32effbf75f646ca78f altering a column in Oracle now always appends a NULL / NOT NULL clause to the column alteration SQL which is wrong if the nullable status has not changed.
During column alteration the clause must only be appended if the nullable status really has changed.



 Comments   
Comment by Marco Pivetta [ 19/Oct/14 ]

Solved in DBAL-1002





[DBAL-1002] [GH-687] [DBAL-1001] Fix NULL / NOT NULL clause for column alterations in Oracle Created: 14/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, oracle, schematool

Issue Links:
Dependency
is required for DBAL-1001 NULL / NOT NULL clause always appende... Resolved

 Description   

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

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

Message:

Due to commit https://github.com/doctrine/dbal/commit/0782e9251a1df353ba589d32effbf75f646ca78f altering a column in Oracle now always appends a `NULL` / `NOT NULL` clause to the column alteration SQL which is wrong if the nullable status has not changed.
During column alteration the clause must only be appended if the nullable status really has changed.
See also: https://github.com/doctrine/dbal/pull/676#issuecomment-57643477



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-1010] [GH-693] [DBAL-1010] Fix renaming column with default value on SQL Server Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, schematool

Issue Links:
Reference
relates to DBAL-830 [GH-539] unit test added for altering... Resolved

 Description   

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

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

Message:

Doctrine throws a fatal error on renaming a column with a default value set because of nested `Identifier` objects as old column name.
This issue was introduced by https://github.com/doctrine/dbal/pull/672.



 Comments   
Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-830] [GH-539] unit test added for altering a column's default where the column name is... Created: 04/Mar/14  Updated: 16/Oct/14  Resolved: 10/Sep/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.2
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: sqlsrv

Issue Links:
Reference
is referenced by DBAL-1010 [GH-693] [DBAL-1010] Fix renaming col... Resolved

 Description   

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

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

Message:

... a keyword - fails on mssql:

Exception : [Doctrine\DBAL\DBALException] An exception occurred while executing 'ALTER TABLE column_keyword_test DROP CONSTRAINT DF_D3D4D2F1_4BF2EAC0':

SQLSTATE [42000, 3728]: [Microsoft][SQL Server Native Client 11.0][SQL Server]'DF_D3D4D2F1_4BF2EAC0' is not a constraint.
SQLSTATE [42000, 3727]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Could not drop constraint. See previous errors.

With queries:
5. SQL: 'ALTER TABLE column_keyword_test DROP CONSTRAINT DF_D3D4D2F1_4BF2EAC0' Params: 
4. SQL: 'SELECT    col.name,
                          type.name AS type,
                          col.max_length AS length,
                          ~col.is_nullable AS notnull,
                          def.definition AS [default],
                          col.scale,
                          col.precision,
                          col.is_identity AS autoincrement,
                          col.collation_name AS collation,
                          CAST(prop.value AS NVARCHAR(MAX)) AS comment -- CAST avoids driver error for sql_variant type
                FROM      sys.columns AS col
                JOIN      sys.types AS type
                ON        col.user_type_id = type.user_type_id
                JOIN      sys.objects AS obj
                ON        col.object_id = obj.object_id
                JOIN      sys.schemas AS scm
                ON        obj.schema_id = scm.schema_id
                LEFT JOIN sys.default_constraints def
                ON        col.default_object_id = def.object_id
                AND       col.object_id = def.parent_object_id
                LEFT JOIN sys.extended_properties AS prop
                ON        obj.object_id = prop.major_id
                AND       col.column_id = prop.minor_id
                AND       prop.name = 'MS_Description'
                WHERE     obj.type = 'U'
                AND       (obj.name = 'column_keyword_test' AND scm.name = SCHEMA_NAME())' Params: 
3. SQL: 'ALTER TABLE column_keyword_test ADD CONSTRAINT DF_D3D4D2F1_ACF51D19 DEFAULT 23 FOR [select]' Params: 
2. SQL: 'CREATE TABLE column_keyword_test ([select] INT NOT NULL)' Params: 

Trace:
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Connection.php:988
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:971
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:612
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\SQLServerSchemaManager.php:232
C:\projects\doctrine\dbal\tests\Doctrine\Tests\DBAL\Functional\Schema\SchemaManagerFunctionalTestCase.php:619
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:976
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:831
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:776
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php:176
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:268
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:506

#0 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\DBALException))
#1 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest))
#3 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), false, Array, Array, false)
#6 C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9 {main}


 Comments   
Comment by Doctrine Bot [ 02/Sep/14 ]

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





[DBAL-1011] [GH-694] [DBAL-1011] Fix column comments containing string literal chars on SQL Server Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, escaping, schematool


 Description   

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

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

Message:

When trying to create or update a column with a comment containing the string literal quote character `'`, SQL generation is invalid and fails on execution. This patch now quotes the particular comment to come around this issue.






[DBAL-1007] [GH-681] Fixed expanding positional parameters which do not start from 0 Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: sql-parser





[DBAL-335] Is MasterSlaveConnection implemented correctly - seems to overwrite master connection on transaction methods? Created: 31/Aug/12  Updated: 16/Oct/14  Resolved: 17/Sep/12

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3
Fix Version/s: 2.3

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

Issue Links:
Dependency
is required for DBAL-1006 [GH-690] Backport [DBAL-717] Fix bug ... Resolved

 Description   

Forgive me to doubt, but I think there may be a bug in MasterSlaveConnection.

It's easier to understand what I'm saying by debugging and tracing the flow, but I'll illustrate it with gists.

First, here is a simple service method to create a user. It opens up a transaction, persists the user, commits and returns. On error, if there is an active transaction, rollback. Here is the gist:

https://gist.github.com/3547674

The "$conn->beginTransaction();" line is where we trace through (the remainder of the service method is now irrelevant). Looking into MasterSlaveConnection.php, we see the method tries to connect to the master connection (call this point ###):

https://gist.github.com/3547720

Now looking in the next gist, we see what happens when "$this->connect('master');" is called. At this point it's not that interesting, the internal "$this->_conn" property is set to "master".

https://gist.github.com/3547750

Now here lies the bug I believe. "parent::beginTransaction();" is called. When looking into this method, we see that another call is made to connect but this time without "master" as the argument (i.e. connect to slave). This call to connect is made before incrementing the transaction nesting level.

https://gist.github.com/3547808

Now, I won't do another gist for "MasterSlaveConnection::connect", but if you refer to the file at line 13 https://gist.github.com/3547750#file_master_slave_connection.php, you will see that it checks the transaction nesting level and if it is there, forces master. However, we don't increment the level until after the method returns, so the slave is used. Ultimately, this results in the internal "$this->_conn" property set to the "slave" connection which violates our original action at ### above where we said we want to connect to "master".

Am I missing something here? Here is a gist the is a basic attempt at fixing this one method. It simply copies the code from the parent method except does not connect twice. I believe the same would have to occur for all the other methods unless it can be fixed once at the "MasterSlaveConnection::connect" level.

https://gist.github.com/3547880

I've just fleshed out "beginTransaction", "commit" and "rollBack" in "MasterSlaveConnection" by basically copying and pasting the code from the parent class and for my failing use case, this fixes the issue. However, it did require updating "Connection" slightly so that I had access to some private variables.



 Comments   
Comment by Lars Strojny [ 31/Aug/12 ]

This looks indeed like a bug. From a first glimpse the fix would be to use master, if master is already connected.

Comment by Benjamin Eberlei [ 05/Sep/12 ]

This only happens when "keepSlave" = true, because then the master is not written into the slave property aswell:

   } else {
     $this->connections['slave'] = $this->_conn = $this->connectTo($connectionName);
   } 

Are you using keepSlave = true?

Comment by Jonathan Ingram [ 05/Sep/12 ]

Yes I am. Does that render this moot or still a bug?

Comment by Benjamin Eberlei [ 06/Sep/12 ]

Its still a bug, but it helps to know why this happens.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

Fixed in master and 2.3, can you test it?

Comment by Jonathan Ingram [ 19/Sep/12 ]

Thanks for doing this. I will test it shortly.

Comment by Ivan Andric [ 22/Sep/12 ]

Hi,

not sure if you managed to test this but now test on mysql database fails with results below.
Probably some typo.

There was 1 error:

1) Doctrine\Tests\DBAL\Functional\MasterSlaveConnectionTest::testKeepSlaveBeginTransactionStaysOnMaster
Exception: [Doctrine\DBAL\DBALException] An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

With queries:
2. SQL: 'CREATE TABLE master_slave_table (test_int INT NOT NULL, PRIMARY KEY(test_int)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params:

Trace:
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DbalFunctionalTestCase.php:73
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:793
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO master_slave_table (test_int) VALUES ' with params

{"1":30}

:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/DBALException.php:47
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92

Caused by
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30' for key 'PRIMARY'

/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:786
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:231
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connection.php:539
/home/ivan/git/dbal2/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php:285
/home/ivan/git/dbal2/dbal/tests/Doctrine/Tests/DBAL/Functional/MasterSlaveConnectionTest.php:92





[DBAL-1006] [GH-690] Backport [DBAL-717] Fix bug in MasterSlaveConnection with keepSlave option and switch back after transaction. Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
depends on DBAL-335 Is MasterSlaveConnection implemented ... Resolved
depends on DBAL-717 Cannot reconnect to slave in some cas... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-717] Cannot reconnect to slave in some cases of keepSlave Created: 21/Dec/13  Updated: 16/Oct/14  Resolved: 21/Dec/13

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

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

Issue Links:
Dependency
is required for DBAL-1006 [GH-690] Backport [DBAL-717] Fix bug ... Resolved
Duplicate
is duplicated by DBAL-527 [GH-323] Update MasterSlaveConnection... Resolved
is duplicated by DBAL-531 [GH-325] Update MasterSlaveConnection... Resolved
is duplicated by DBAL-519 MasterSlave connection does not keep ... Resolved

 Description   

See https://github.com/doctrine/dbal/pull/325 and https://github.com/doctrine/dbal/pull/326



 Comments   
Comment by Doctrine Bot [ 21/Dec/13 ]

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





[DBAL-527] [GH-323] Update MasterSlaveConnection.php Created: 22/May/13  Updated: 16/Oct/14  Resolved: 21/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-717 Cannot reconnect to slave in some cas... Resolved

 Description   

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

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

Message:

check $this->keepSlave before enforcing master as slave



 Comments   
Comment by Doctrine Bot [ 21/Dec/13 ]

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

Comment by Benjamin Eberlei [ 21/Dec/13 ]

Duplicate of DBAL-717

Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-531] [GH-325] Update MasterSlaveConnectionTest.php Created: 26/May/13  Updated: 16/Oct/14  Resolved: 21/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-717 Cannot reconnect to slave in some cas... Resolved

 Description   

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

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

Message:

the test testKeepSlaveBeginTransactionStaysOnMaster does not begin a transaction, I have put a begin transaction, and now it fails,

the fix is here, if it makes sense
https://github.com/ananda-agrawal/dbal/commit/eb9262afb3955e4974d5a713b495a544b66a5cf7



 Comments   
Comment by Doctrine Bot [ 21/Dec/13 ]

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

Comment by Benjamin Eberlei [ 21/Dec/13 ]

Duplicate of DBAL-717

Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DBAL-1005] Timezones of DateTime instances are ignored when persisting dates Created: 15/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Brent Shaffer Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

When a DateTime instance, e.g. "2011-02-16 00:00:00 America/New_York" is written into the DB, the timezone is ignored and only "2011-02-16" is persisted. When fetching the date, it is written into a DateTime with the server's timezone, resulting in for example "2011-02-16 00:00:00 Europe/Berlin" which is not correct!

To fix this issue, Doctrine should convert dates to the server's timezone (if their own timezone differs) before persisting them or before executing queries containing DateTime instances.



 Comments   
Comment by Brent Shaffer [ 15/Oct/14 ]

I would like to reopen this issue - Doctrine is expecting the incoming DateTime objects to have the system's default_timezone. If they do NOT use the default timezone (let's say they, instead use UTC), then the date is saved in the format of the default timezone anyway, and upon hydration, the UNIX timestamp changes.

I don't see how this could ever be considered expected behavior. Doctrine is essentially modifying the timestamp being persisted.

Doctrine should set the timezone of the DateTime object prior to persistence using the date_default_timezone_get() method. Either that, or the persisted string should contain the timezone identifier of the initial DateTIme object.

Comment by Marco Pivetta [ 15/Oct/14 ]

See http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/working-with-datetime.html

The current DateTime type completely ignores timezones and we will keep it like that for now.

Comment by Brent Shaffer [ 15/Oct/14 ]

@Marco thank you for your quick reply. Can you help me understand why the decision was made to expect the timezone to be the default instead of just setting it to be that way before persistence? It seems like all these woes could have been easily avoided...

Comment by Marco Pivetta [ 15/Oct/14 ]

Brent Shaffer it was indeed a mistake to not use stricter rules on DateTime instances, but due to the amount of code depending on this behavior right now, we cannot change the Doctrine\DBAL\Types\DateTimeType anymore.

Instead, we may consider introducing a new UTC-based datetime-type for 3.x.

A change is not going to be applied on existing logic.





[DBAL-472] Oracle schema modification - incorrect SQL to change the nullable status of column Created: 26/Mar/13  Updated: 14/Oct/14  Resolved: 29/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.2
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Andy Park Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

Centos 6 PHP 5.3.3 Oracle 11g


Issue Links:
Reference
is referenced by DBAL-1001 NULL / NOT NULL clause always appende... Resolved

 Description   

When updating the nullable status of a column the sql generated is

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) DEFAULT NULL)

This will set the default column value to null but does not modify the nullable status of the column. The correct sql would be

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) NULL)

The field definition changed from

metar:
type: string
length: 2000
nullable: false
column: METAR

to

metar:
type: string
length: 2000
nullable: true
column: METAR



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

Works for me strangely.

Comment by Steve Müller [ 27/Dec/13 ]

Patch supplied in PR: https://github.com/doctrine/dbal/pull/467

Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-998] [GH-686] Add test for explicit positional parameter keys in SQLParserUtils Created: 08/Oct/14  Updated: 08/Oct/14  Resolved: 08/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

To prove PR #681 is working correctly.






[DBAL-996] [GH-684] Changed the composer constraint to allow Common 2.5 Created: 05/Oct/14  Updated: 07/Oct/14  Resolved: 07/Oct/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

I also changed the PHPUnit dev constraint to allow usign supported versions (the latest is 4.2, not 4.0)






[DBAL-995] [GH-683] Fix phpDoc comments to return $this instead of fully qualified class name Created: 03/Oct/14  Updated: 03/Oct/14  Resolved: 03/Oct/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Scenario:
Im extending the QueryBuilder class, adding new methods and returning $this.

In the latest PhpStorm(and probably other editors) the higlighter sees an error because the inherited methods return an exact class name of the parent instead of $this.






[DBAL-994] [GH-682] [WIP] [DBAL-218] Add bulk insert query Created: 30/Sep/14  Updated: 30/Sep/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

This is an approach to make use of database vendors' bulk row insert query syntax.
As the nature of bulk inserts usually is to insert a LOT of rows into a table (primarily from an external source), the implementation tries to focus on good performance and low memory consumption. It is NOT intended for `INSERT INTO ... SELECT ...` statement queries.

TODO:

  • Add an "executor" class that encapsulates the `BulkInsertQuery` object, adds options like bulk size and internally automatically evaluates the underlying platform's limits for a single `INSERT` statement and splits queries accordingly.
  • Evaluate platforms' max insert rows per `INSERT` statement and implement in platforms.
  • Add unit tests for quoted identifiers.
  • Add functional tests.

Future additions:

  • Add support for expressions.
  • Query builder (if there will be more bulk insert queries like `INSERT INTO ... SELECT ...`)?

Open for discussion. Ideas welcome!






[DBAL-608] [GH-372] HHVM compatibility: func_get_args Created: 15/Sep/13  Updated: 22/Sep/14  Resolved: 15/Sep/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2681 [GH-790] HHVM compatibility: func_get... Resolved
is referenced by DDC-3317 [GH-1142] func_get_args() call order ... Resolved

 Description   

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

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

Message:

All func_get_args() calls have been moved to the top of the methods because HHVM doesn't keep a copy of the original args for performance reasons.

See facebook/hiphop-php#1027 for details.



 Comments   
Comment by Doctrine Bot [ 15/Sep/13 ]

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

Comment by Guilherme Blanco [ 15/Sep/13 ]

Merged

Comment by Doctrine Bot [ 22/Sep/14 ]

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





[DBAL-842] [GH-548] DBAL-774 - added failing test for parsing order of joins Created: 21/Mar/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-774 DBAL parses joins in wrong order Resolved
is referenced by DBAL-991 [GH-679] [DBAL-774] Fix QueryBuilder ... Resolved

 Description   

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

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

Message:

I had finaly some time to investigate the problem a bit more, and the problem is the way doctrine/dbal >= 2.4 handles the parsing of joins

The expected result is the way doctrine/dbal 2.3 handles the joins, which is not quite the way i expect that the query would be outputted but it is correct for execution.



 Comments   
Comment by Jeroen Thora [ 21/Mar/14 ]

Pullrequest related to DBAL-774

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-774] DBAL parses joins in wrong order Created: 08/Jan/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.4, 2.5, 2.4.1, 2.4.2
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Critical
Reporter: Jeroen Thora Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: querybuilder

Issue Links:
Reference
is referenced by DBAL-842 [GH-548] DBAL-774 - added failing tes... Resolved
is referenced by DBAL-991 [GH-679] [DBAL-774] Fix QueryBuilder ... Resolved

 Description   

I have a problem that doctrine dbal orders the joins in a wrong order if you use more complex join combinations (worked fine in DBAL 2.3)

Dbal Querybuilder:

        $qb->select('tbl_profile_additional_property.pkid AS pkid')
        ->from('tbl_profile_additional_property', 'tbl_profile_additional_property')
        ->leftjoin('tbl_profile_additional_property', 'tbl_rating_system', 'tbl_rating_system', 'tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid')
        ->leftjoin('tbl_rating_system', 'tbl_rating_system_translation', 'tbl_rating_system_translation', 'tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid')
        ->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')
        ->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')
        ->where('tbl_profile_additional_property.fk_function = :functionid')
        ->setParameter('functionid', $functionId)
        ->setParameter('languageid', $languageId);

Expected Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

Resulted Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

(The last 2 LEFT JOINS of the query are the problem)

The problem is with getSQLForJoins it loops over all the joins and foreach join it follows all the used joins aliases until the deepest point. Therefor it will parse this join first

->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')

Before it generates the sql for this line (this line is needed becaus the line above needs a join on tbl_score_level first)

->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')

The order the querybuilder in php is build (select, from, joins, etc) is the order it should be parsed as sql.

Ps. I have added 2.5 also as affectsversion because the code didn't change as far is i know



 Comments   
Comment by Chesley Brown [ 22/Jan/14 ]

Noticing this issue with v2.4 as well. However, I'm also noticing the leftJoins being ordered incorrectly on v2.3.3 as well... however the ordering between the two versions are not the same. They are both just ordered differently than the order that I actually call the leftJoin methods in.

Comment by Jeroen Thora [ 21/Mar/14 ]

I have added a failing test for this problem in doctrine/dbal#548

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Marco Pivetta [ 17/Sep/14 ]

Resolved in DBAL-991 - won't be backported in 2.4 as 2.4 behavior could radically change otherwise.





[DBAL-991] [GH-679] [DBAL-774] Fix QueryBuilder parsing order of joins Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-774 DBAL parses joins in wrong order Resolved
relates to DBAL-842 [GH-548] DBAL-774 - added failing tes... Resolved

 Description   

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

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

Message:

This is a fix for DBAL-774(http://www.doctrine-project.org/jira/browse/DBAL-774) and is the followup for PR #548.



 Comments   
Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-989] Tag new version for 2.3.x Created: 15/Sep/14  Updated: 17/Sep/14  Resolved: 15/Sep/14

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

Type: Task Priority: Major
Reporter: Jeroen Thora Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

Hi,

Would it be possible to release a new version of doctrine 2.3.x? I stumbled into this issue DBAL-522 and there was a fix (and merged in 2.3 branch). Don't know if you still support the 2.3 version, but there were some fixes done which are not included in a tag/release. See 2.3.4...2.3 diff

In the 2.4 branch (releases) this is fixed but because of issue DBAL-774 i'm unable to upgrade to 2.4

Thanks



 Comments   
Comment by Marco Pivetta [ 15/Sep/14 ]

A new 2.3.x should be viable: can you backport the patch into a PR targeted at the 2.3 branch?

Comment by Jeroen Thora [ 15/Sep/14 ]

The fix for this issue was already backported into the 2.3 branch, but it wasn't included in any release so far. But I just saw that deeky released a new 2.3.5 version, so as far as i can see now, this should be fixed. But will confirm tomorrow!

Comment by Steve Müller [ 15/Sep/14 ]

Jeroen Thora yes, released 2.3.5 today. Blog post will follow later.

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-990] [GH-678] Clean up unused uses Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Getting rid of unused `use` statements



 Comments   
Comment by Doctrine Bot [ 17/Sep/14 ]

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

Comment by Doctrine Bot [ 17/Sep/14 ]

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





[DBAL-552] Colon (":") in field name treats like query parameter Created: 25/Jun/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5, 2.4.2, 2.3.5
Security Level: All

Type: Bug Priority: Major
Reporter: Daniel Bojdo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

MySQL


Issue Links:
Reference
is referenced by DBAL-624 Parameter in comments is parsed Open

 Description   

The colon sign (":") is permitted for columns' name but Doctrine treats them like parameters placeholder:

SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1

causes DBALException:

An exception occurred while executing 'SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1' with params ["2013-06-24 14:22:18"]: Value for :col_name not found in params array. Params array key should be "col_name"


 Comments   
Comment by Benjamin Eberlei [ 25/Jun/13 ]

does this work with plain PDO?

Comment by Daniel Bojdo [ 25/Jun/13 ]

Yes, it works perfectly fine with PDO. It also works properly with Doctrine\DBAL\Connection.
I suppose there's a bug somewhere in QueryBuilder.

Comment by Steve Müller [ 29/Dec/13 ]

Patch supplied in PR: https://github.com/doctrine/dbal/pull/477

Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-766] PostgreSQL: Fix statement for getTableWhereClause method Created: 05/Jan/14  Updated: 15/Sep/14  Resolved: 05/Jan/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5, 2.4.3, 2.3.5
Security Level: All

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


 Description   

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






[DBAL-760] [GH-490] Don't return warnings as errors in sqlsrv driver Created: 03/Jan/14  Updated: 15/Sep/14  Resolved: 03/Jan/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5, 2.4.3, 2.3.5
Security Level: All

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


 Description   

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

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

Message:

The SQL Server platforms use `sp_rename` stored procedure for renaming schema objects like tables, indexes or columns. SQL Server raises a warning when invoking this stored procedure, although the result is as expected:

```php
Doctrine\DBAL\Driver\SQLSrv\SQLSrvException: SQLSTATE [01000, 15477]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Vorsicht: Wenn Sie Teile eines Objektnamens ��ndern, werden Skripts und gespeicherte Prozeduren m��glicherweise funktionsunf��hig.
```

This PR configures the sqlsrv driver not to handle warnings returned from the server as errors to prevent this. The PDO_SQLSRV driver silences warnings, too.



 Comments   
Comment by Doctrine Bot [ 03/Jan/14 ]

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





[DBAL-741] [GH-474] Fix foreign key columns order in Oracle Created: 28/Dec/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4, 2.5, 2.3.5
Security Level: All

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


 Description   

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

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

Message:

The order of columns in foreign key constraints is not synchronized by the Oracle platform.

*Failing test:*
```bash
Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest::testListForeignKeysComposite
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array (

  • 0 => 'id'
  • 1 => 'foreign_key_test'
    + 0 => 'foreign_key_test'
    + 1 => 'id'
    )

/home/deeky/dev/doctrine/dbal/tests/Doctrine/Tests/DBAL/Functional/Schema/SchemaManagerFunctionalTestCase.php:672
```



 Comments   
Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-742] [GH-475] Fix column default value introspection in Oracle Created: 28/Dec/13  Updated: 15/Sep/14  Resolved: 29/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5, 2.4.2, 2.3.5
Security Level: All

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


 Description   

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

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

Message:

A bug in `OracleSchemaManager` cause a column's default value always to be null. Besides that default values are enclosed in single quotes when retrieved from database which is not evaluated by the schema manager, either.
This PR also fixes the default value tests in Oracle's functional test suite.



 Comments   
Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DBAL-589] Doctrine\DBAL\Schema\Column::visit has an Invalid Type Hint Created: 27/Aug/13  Updated: 15/Sep/14  Resolved: 21/Nov/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.4
Fix Version/s: 2.3.5

Type: Bug Priority: Minor
Reporter: Christopher Davis Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

$ php -v
PHP 5.4.15 (cli) (built: Aug 16 2013 15:38:16)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

$ uname -a
Darwin chrispmg.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64



 Description   

Column::visit typehints against a class that doesn't exist (`Doctrine\DBAL\Schema\Visitor`).

https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L398

Looks like there's a `use` statement at the top of the file that imports the correct class: https://github.com/doctrine/dbal/blob/2.3/lib/Doctrine/DBAL/Schema/Column.php#L23






[DBAL-613] [GH-377] Fixed logic error in Sharding component Created: 24/Sep/13  Updated: 15/Sep/14  Resolved: 26/Sep/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3, 2.4
Fix Version/s: 2.5, 2.4.1, 2.3.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: sharding


 Description   

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

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

Message:

No need to choose shard by chooser, as is pass the identifiers shard.



 Comments   
Comment by Doctrine Bot [ 26/Sep/13 ]

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





[DBAL-522] BC break : executeQuery with an array containing null value(s). Created: 20/May/13  Updated: 15/Sep/14  Resolved: 21/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: 2.4, 2.3.5

Type: Bug Priority: Blocker
Reporter: lemeunier Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal
Environment:

Mac OSX 10.8.3, Mysql 5.5.28, PHP5.4



 Description   

Hello, i have got an error with doctrine 2.3.4 when i try to run the following code :

 
    $conn->executeQuery(
        'INSERT INTO FOO (foo, bar) values (:foo, :bar)', 
         array('foo' => 1, 'bar' => null)
     );

Error : Value for :bar not found in params array. Params array key should be "bar"

This code worked with doctrine 2.3.3.

I think the error comes from the function 'extractParam' in SQLParserUtils.php (DBAL)

line 215 : if (isset($paramsOrTypes[$paramName]))

The key exists even if the value is null.
So it should be:

  if (array_key_exists($paramName, $paramsOrTypes)) 

I am not enough confident to try a PR.
Thanks in advance!



 Comments   
Comment by Marco Pivetta [ 20/May/13 ]

I suggested a hotfix at https://github.com/doctrine/dbal/pull/322

Comment by lemeunier [ 21/May/13 ]

Thanks for the hotfix.





[DBAL-988] [GH-677] avoid recursive quoteIdentifier call Created: 11/Sep/14  Updated: 12/Sep/14  Resolved: 12/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

each $part does not contain ".", so quoteSingleIdentifier may be called directly thus avoiding recursive strpos checks.



 Comments   
Comment by Steve Müller [ 12/Sep/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/0d99f152573c2da1a4884cc90a9fdfc038f47f7b





[DBAL-816] [GH-529] fix for postres listTableNames Created: 18/Feb/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

fix for listTableNames to return unescaped table names



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-987] [GH-675] [DBAL-959] Allow to get bound parameter types from query builder Created: 11/Sep/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DBAL-959 [GH-648] Allow to get bound parameter... Resolved

 Description   

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

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

Message:

Replaces https://github.com/doctrine/dbal/pull/648.

Added tests.



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-449] [GH-274] Support column charset/collation on capable platforms Created: 19/Feb/13  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

Basically the same feature wanted as in #245



 Comments   
Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-647] MySqlPlatform's getCollationFieldDeclaration() looks like it has the wrong name Created: 01/Nov/13  Updated: 11/Sep/14  Resolved: 26/Nov/13

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

Type: Bug Priority: Major
Reporter: John Flatness Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None


 Description   

The MySqlPlatform has a method getCollationFieldDeclaration(). As far as I can tell, that method's not actually used for anything.

However, looking at the other Platforms and the AbstractPlatform, it looks like this method is what is elsewhere called getColumnCollationDeclarationSQL().

The AbstractPlatform calls getColumnCollationDeclarationSQL() when getting the SQL for a column with a "collation" set; for MySQL, this currently causes no effect since the default, blank implementation from the AbstractPlatform is being used.

It looks like the name of this method should be changed.



 Comments   
Comment by John Flatness [ 05/Nov/13 ]

The current name of the method looks like it dates back to the initial refactorings for Doctrine 2. No other methods there still use the "Field" terminology in the method name, and all the others that return snippets of SQL uniformly use "DeclarationSQL" instead of just "Declaration".

That combined with the different name for seemingly the same method in the AbstractPlatform and SQLServerPlatform makes it seem like this one just got left behind.

Comment by Steve Müller [ 25/Nov/13 ]

The reason for this diverge in implementation and terminology is that there still is an open PR that enables support for column collation declaration on capable platforms which is not yet merged:

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

and

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

Partial support for SQL Server has already been merged in:

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

This feature is nearly finished and about to be merged. AbstractPlatform::getCollationFieldDeclaration() will be deprecated then to ensure BC. Does that answer your question? =) If so, can this ticket be closed?

Comment by John Flatness [ 26/Nov/13 ]

I believe that does answer my question.

One little thing: when you say AbstractPlatform::getCollationFieldDeclaration() will be deprecated, you mean the one on MysqlPlatform, right? I believe there is no such method on the AbstractPlatform.

Comment by Steve Müller [ 26/Nov/13 ]

Yes it will be deprecated in MySQLPlatform. See the PR.
Can you tell me what is still unclear? Or what you'd expect of this ticket?

Comment by John Flatness [ 26/Nov/13 ]

Okay, then I think it was just a typo in your first comment.

PR #245 on Github seems like it covers this squarely, so I suppose this issue doesn't stand for much on its own.

Comment by Steve Müller [ 26/Nov/13 ]

You are right it was not supposed to be AbstractPlatform but MySQLPlatform

Comment by Doctrine Bot [ 11/Feb/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-959] [GH-648] Allow to get bound parameter types from query builder. Created: 04/Aug/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Dependency
depends on DBAL-987 [GH-675] [DBAL-959] Allow to get boun... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DBAL-423] Type GUID = VARCHAR(255) on platforms that don't have a native GUID support Created: 25/Jan/13  Updated: 10/Sep/14  Resolved: 10/Sep/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5

Type: Improvement Priority: Minor
Reporter: amr Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Dependency
depends on DBAL-731 [GH-465] [DBAL-423] Optimize non-nati... Resolved

 Description   

I'm using MySQL with entities that have GUID ids. Therefore I'm using @ORM\Column(type="guid") for the ORM mapping. As MySQL does not have a native GUID data type, it gets mapped to type="string" with a default length of 255 -> VARCHAR(255). I don't really understand why we don't limit the length to 36, which is the fixed length for GUIDs. You could even think about using CHAR(36) for MySQL.

-> see Doctrine\DBAL\Platforms\AbstractPlatform -> getGuidTypeDeclarationSQL()



 Comments   
Comment by Steve Müller [ 23/Dec/13 ]

Patch PR: https://github.com/doctrine/dbal/pull/465

Comment by Michael Kühn [ 28/Feb/14 ]

With the latest support for the MyISAM-Engine merging this pull request would save some trouble.

Background/Steps to reproduce:
If you have 2 entities with guid/uuid as primary key, @ManyToMany/@JoinTable fails on MyISAM, because it would create a jointable with 2 VARCHAR(255) columns and would apply a combined primary key on these two columns. But MyISAM doesn't support keys longer than 1000 bytes so you can't create the jointable.

See: https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html

The maximum key length is 1000 bytes. This can also be changed by changing the source and recompiling. For the case of a key longer than 250 bytes, a larger key block size than the default of 1024 bytes is used.

In my opinion this isn't just a "minor" issue but a major because some people can't run on MySQL with InnoDB for some reason.

Comment by Marco Pivetta [ 28/Feb/14 ]

Michael Kühn MyISAM is niche support for the ORM - using a custom type is perfectly fine in such a case.

Comment by Michael Kühn [ 04/Mar/14 ]

Marco Pivetta I agree, but i don't see why we would assume a GUID/UUID - which is per definition 36 chars long - as a 255 char long string. It would save storage space (for platforms don't supporting a native uuid type) and circle around at least 1 barrier if using MyISAM.

By the way, the PR is missing something. While it works perfectly fine the first time, every orm:schema-tool:update would output the guid-columns every time if you don't specifiy "length=36" and "fixed=true" on every GUID-@Column. IMHO the GUID-Type should implicit this both attributes in this pull request so you don't get column updates that don't change anything.

Comment by Steve Müller [ 08/Mar/14 ]

Michael Kühn I get your point and thanks for pointing out the remaining issue. The problem is caused by the comparator which detects differences in the column definition because the length and fixed attribute are hardcoded in the platform which is beyond comparator's knowledge. Still I think this can be fixed easily but as long as Benjamin Eberlei is of the opinion that this change is a minor BC break, this PR won't make it into the master branch.

Comment by Doctrine Bot [ 10/Sep/14 ]

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

Comment by Marco Pivetta [ 10/Sep/14 ]

Resolved in DBAL-731





[DBAL-731] [GH-465] [DBAL-423] Optimize non-native GUID type declaration Created: 23/Dec/13  Updated: 10/Sep/14  Resolved: 10/Sep/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DBAL-423 Type GUID = VARCHAR(255) on platforms... Resolved

 Description   

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

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

Message:

Currently non-native GUID type is mapped to `VARCHAR(255)` which is not effective as GUID always has a fixed length of 36 characters. Therefore it should be mapped to `CHAR(36)` instead.



 Comments   
Comment by Doctrine Bot [ 10/Sep/14 ]

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





[DBAL-934] [GH-628] bug fix for db2 v10 new column def of syscat.columns.default Created: 05/Jul/14  Updated: 10/Sep/14  Resolved: 10/Sep/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

It seems like ibm changed the column type of the column named "default" in syscat.columns in db2 luw v10. Probably in db2z too, but I haven't looked.

in v9.7 it was VARCHAR(254)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_9.7.0%2F2-10-7-17&lang=en

in 10.1 its CLOB(64k)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_10.1.0%2F2-9-8-18&lang=en

This causes an sql statement to fail. In
file: doctrine/dbal/lib/Doctrine/DBAL/Platforms/DB2Platform.php
method: getListTableColumnsSQL()

We make some sql like

SELECT DISTINCT c.tabschema, c.tabname, c.colname, c.colno,
c.typename, c.default, c.nulls, c.length, c.scale,
c.identity, tc.type AS tabconsttype, k.colseq
FROM syscat.columns c
...

This causes an exception like:
[IBM][CLI Driver][DB2/LINUXX8664] SQL0134N Improper use of a string column, host variable, constant, or function "DEFAULT". SQLSTATE=42907 SQLCODE=-134

The key problem here seems to be that you can't include a CLOB column in a select distinct.

At the very least, this breaks the command line tool for orm:schema-tool:update, although it might break other stuff too that I'm not aware of.

There's probably a cleaner query we can use, but I'm not familiar with the code base and what can/can't change. I don't want to introduce a bug, so I took the safe route and just did the ugly
subquery and join that shouldn't disturb anything. It's not like we need performance here.

I added a test which compares the results of the previous query with my new one. Seems to work. The test isn't something I expect to be added to your test suite - I figure someone else will run it manually to confirm my changes and then delete the test.






[DBAL-986] [GH-674] Fix typos Created: 03/Sep/14  Updated: 03/Sep/14  Resolved: 03/Sep/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 03/Sep/14 ]

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

Comment by Doctrine Bot [ 03/Sep/14 ]

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





[DBAL-985] [GH-673] Fix DocBlock type hint Created: 02/Sep/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

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

Type: Documentation Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

`$changedColumns` is actually an array of `Doctrine\DBAL\Schema\ColumnDiff` instances.



 Comments   
Comment by Doctrine Bot [ 02/Sep/14 ]

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

Comment by Doctrine Bot [ 02/Sep/14 ]

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