[DBAL-984] [GH-671] Fix quoted integers as default value. Created: 28/Aug/14  Updated: 29/Aug/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





[DBAL-983] [GH-670] Handle default values for boolean, datetime, and datetimetz columns in PostgreSQL Created: 27/Aug/14  Updated: 28/Aug/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/670

Message:

When dealing with legacy schema it would be nice to be able to map default values and not have the schema spit out `ALTER` statements each time. This works correctly today for basic integer and string columns, but does not handle columns with special types such as `boolean` or `datetime`.

For example, the following statement:

`ALTER TABLE test_table ALTER test_column SET DEFAULT CURRENT_TIMESTAMP;`

Results in a column definition like:

`test_column | timestamp with time zone | not null default now()`

However, repeating the same schema generation will result in the same `ALTER` statement each time, because it will always detect that the default value has changed. The same is true for boolean columns.

This simple change prevents this situation from happening and correctly detects that the column default has not changed. It is specific to PostgreSQL.



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

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





[DBAL-982] [GH-669] Correct schema generation for altering PostgreSQL sequences Created: 25/Aug/14  Updated: 25/Aug/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





[DBAL-981] [GH-668] Fix: Travis-CI configuration Created: 24/Aug/14  Updated: 24/Aug/14  Resolved: 24/Aug/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 till:

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

Message:

Reference: http://till.klampaeckel.de/blog/archives/204-Whats-wrong-with-composer-and-your-.travis.yml.html



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

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





[DBAL-873] [GH-571] Introduced a Transaction object Created: 18/Apr/14  Updated: 23/Aug/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 BenMorel:

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

Message:

This is a first draft on the idea of a Transaction object, as suggested by @guilhermeblanco and @beberlei in doctrine/doctrine2#949.

This makes the following changes to `Connection`:

  • *Adds* the following methods:
  • `createTransaction()` : begins a transaction and returns the associated `Transaction` object
  • `getTransactionManager()` : returns the `TransactionManager`
  • *Deprecates* `beginTransaction()` in favour of `createTransaction()`
  • *Deprecates* the following methods, in favour of their counterparts on `Transaction`:
  • `commit()`
  • `rollBack()`
  • `setRollbackOnly()`
  • `isRollbackOnly()`
  • *Deprecates* the following methods, in favour of their counterparts on `TransactionManager`:
  • `isTransactionActive()`
  • `getTransactionNestingLevel()`
  • `setNestTransactionsWithSavepoints()`
  • `getNestTransactionsWithSavepoints()`

The new way of dealing with transactions is then:

$transaction = $connection->createTransaction();
$transaction->commit();

It also automatically propagates `commit()` and `rollback()` to nested transactions:

$transaction1 = $connection->createTransaction();
$transaction2 = $connection->createTransaction();
$transaction1->commit(); // will commit $transaction2 then $transaction1

Overall, it's not a complicated change, does not introduce any BC break, and passes all existing tests.

I'm looking forward to hearing what you think!



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

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





[DBAL-980] [GH-667] Add tests for select all behaviour when not using a table alias Created: 21/Aug/14  Updated: 22/Aug/14  Resolved: 22/Aug/14

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

Type: Improvement Priority: Trivial
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 JeroenDeDauw:

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

Message:



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/14f730fb2e02df2c1daf8df09057b6771d5c226a





[DBAL-977] [GH-664] [DBAL-669] Make schema visit namespaces Created: 21/Aug/14  Updated: 21/Aug/14  Resolved: 21/Aug/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: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-669 Postgresql platform schema creation f... Resolved

 Description   

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

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

Message:

This PR is a followup to https://github.com/doctrine/dbal/pull/444 and fixes schema not visiting namespaces.
Because of this issue the ORM test suite is [currently failing](https://travis-ci.org/doctrine/doctrine2/jobs/32975659). The schema tool is not creating the namespaces before actually creating the namespace prefixed tables, therefore one test case is failing in ORM.
With this PR now the `CreateSchemaSqlCollector` is also generating the appropriate namespace creation SQL.



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

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

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

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





[DBAL-924] [GH-619] fix all sqlite integer types Created: 16/Jun/14  Updated: 21/Aug/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





[DBAL-979] [GH-666] [DBAL-924] Fix SQLite integer type primary autoincrement columns Created: 21/Aug/14  Updated: 21/Aug/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





[DBAL-704] [GH-444] DBAL-669 - Update SQL for generated by the schema tool will also create schemas Created: 13/Dec/13  Updated: 21/Aug/14  Resolved: 13/Dec/13

Status: Closed
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: Duplicate 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/444

Message:

DBAL-669 - Updating a schema should introduce also schema creation statements in the generated SQL



 Comments   
Comment by Marco Pivetta [ 13/Dec/13 ]

Duplicate of DBAL-669

Comment by Doctrine Bot [ 22/Dec/13 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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





[DBAL-923] [GH-618] sqlite does not support bigint Created: 12/Jun/14  Updated: 21/Aug/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





[DBAL-978] [GH-665] convenience method for FULL OUTER JOINs in QueryBuilder Created: 21/Aug/14  Updated: 21/Aug/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 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






[DBAL-669] Postgresql platform schema creation fails if it already exists Created: 18/Nov/13  Updated: 21/Aug/14  Resolved: 18/Aug/14

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

Type: Bug Priority: Major
Reporter: Chris Ramakers Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

Postgresql 8.3.14 on CentOS6
Also happens on Postgresql 9.2 on the same box


Issue Links:
Reference
is referenced by DBAL-977 [GH-664] [DBAL-669] Make schema visit... Resolved

 Description   

This patch (https://github.com/doctrine/dbal/commit/fabe3c346b24dcb70eba0cb3936998ec6cc152f0) introduced a bug where the schemaNeedsCreation method always returns true if the schema name isn't 'default' or 'public'.

We heavily use schema's in our application and whenever an insert query is queued, it fails because the schema in question already exists but the platform adapter fails to detect that and continues with a "CREATE SCHEMA" query which fails.

The easy fix is to add the 'IF NOT EXISTS' clause to the 'CREATE SCHEMA' query but that will only function on Postgresql 9.3 and upward since 'IF NOT EXISTS' wasn't possible in earlier versions for schema creation.

Beter would be to load the existing schema's and compare them to those. I would create a pull request but i'm not sure how to obtain a database connection in the Platform (if at all possible) to pull a list of already known schema's?



 Comments   
Comment by Marco Pivetta [ 13/Dec/13 ]

Chris Ramakers I'm trying to look into it. The method

schemaNeedsCreation

seems indeed to be wrong.

Comment by Marco Pivetta [ 13/Dec/13 ]

Provided a fix for this at https://github.com/doctrine/dbal/pull/444

We won't fix the schema creation command, since it is supposed to fail on already existing conflicting elements (tables/etc)

Comment by Chris Ramakers [ 02/Apr/14 ]

Any news on this? The bug keeps causing problems every time we deploy a new version. We are practically required to edit the vendor files for doctrine in our project so this bug doesn't cause issues.





[DBAL-783] [GH-508] [DDC-2310] Fix evaluation of NOLOCK table hint on SQL Server Created: 13/Jan/14  Updated: 20/Aug/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





[DBAL-976] [GH-663] [DDC-2310] [2.4] Fix evaluation of NOLOCK table hint on SQL Server Created: 20/Aug/14  Updated: 20/Aug/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





[DBAL-975] [GH-662] Allow current timestamp default to be specified for DateTimeTz type. Created: 17/Aug/14  Updated: 19/Aug/14  Resolved: 19/Aug/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 sarcher:

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

Message:

Currently there is no way to specify a current timestamp as a default when using the `DateTimeTz` type, as it will always be quoted by the system. For example, the generated schema would have:

`DEFAULT 'NOW()'`

Instead of the correct:

`DEFAULT NOW()`

This simple fix allows `DateTimeTz` to behave just as `DateTime` in this regard.



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

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

Comment by Doctrine Bot [ 19/Aug/14 ]

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





[DBAL-900] [GH-600] Support for Partial Indexes for PostgreSql Created: 07/May/14  Updated: 19/Aug/14  Resolved: 19/Aug/14

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

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

Issue Links:
Dependency
is required for DDC-3117 [GH-1027] Support for Partial Indexes... Open

 Description   

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

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

Message:

Support for Partial Indexes was available in Doctrine 1 following
http://www.doctrine-project.org/jira/browse/DC-82. This commit
reintroduce support for Doctrine 2. We use the same syntax with an
optionnal "where" attribute for Index and UniqueConstraint.

It is unit-tests covered and documented in manual.



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

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

Comment by Doctrine Bot [ 16/May/14 ]

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

Comment by Doctrine Bot [ 02/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Aug/14 ]

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

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

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





[DBAL-563] Oracle "IDENTITY" last inserted ID is returning 0 instead of the real ID Created: 19/Jul/13  Updated: 18/Aug/14  Resolved: 31/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: Mohammad A. ZeinEddin Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: cascade, lastInsertedId, oci8, oracle
Environment:

Oracle, OCI8


Attachments: File LastInsertId.php     File OCI8Connection.php     File OCI8Statement.php    
Issue Links:
Reference
is referenced by DDC-2875 [GH-890] [DBAL-563] Add general IDENT... Resolved

 Description   

I am using doctrine 2 with oracle, the tables in the database has some triggers that generate the IDs, and I am trying to us Doctrine 2 cascade persist when mapping on one-to-many, and I use "IDENTITY" in the mapping, but there is a problem which is the one-side of the relation is returning 0 as last inserted ID, which is wrong, my ID mapping of my tables is like the following:

/**

  • @orm\Id
  • @orm\Column(type="integer");
  • @orm\GeneratedValue(strategy="IDENTITY")
    */
    protected $id;

and my entities looks like the following:

/**

  • @ORM\Entity
  • @ORM\Table(name="clients")
    **/
    class Client {
    /**
  • @ORM\Id
  • @ORM\GeneratedValue(strategy="IDENTITY")
  • @ORM\Column(type="integer")
    */
    protected $id;

/** @ORM\Column(name="name",type="string",length=255,unique=true) */
protected $name;

/**

  • @ORM\OneToMany(targetEntity="ContactInformation", mappedBy="client", cascade= {"persist"}

    )
    **/
    protected $contactInformations;

public function __construct()

{ $this->contactInformations = new ArrayCollection(); }

public function getId()

{ return $this->id; }

public function getName() { return $this->name; }

public function setName($name) { $this->name = $name; return $this; }

public function getContactInformations() { return $this->contactInformations; }

public function addContactInformations(Collection $contactInformations)
{
foreach ($contactInformations as $contactInformation) { $contactInformation->setClient($this); $this->contactInformations->add($contactInformation); }
}

/**
* @param Collection $tags
*/
public function removeContactInformations(Collection $contactInformations)
{
foreach ($contactInformations as $contactInformation) { $contactInformation->setClient(null); $this->contactInformations->removeElement($contactInformation); }
}

public function setContactInformations($contactInformations) { $this->contactInformations = $contactInformations; return $this; }
}

and the other entity:

/**
* @ORM\Entity
* @ORM\Table(name="contact_informations")
**/
class ContactInformation {
/**
* @ORM\Id
* @ORM\GeneratedValue(strategy="IDENTITY")
* @ORM\Column(type="integer")
*/
protected $id;

/**
* @ORM\OneToOne(targetEntity="ContactInformationType")
* @ORM\JoinColumn(name="type_id", referencedColumnName="id")
**/
protected $type;

/** @ORM\Column(type="text") */
protected $value;

/**
* @ORM\ManyToOne(targetEntity="Client", inversedBy="contact_informations")
* @ORM\JoinColumn(name="client_id", referencedColumnName="id")
**/
private $client;

public function getId() { return $this->id; }

public function getType()

{ return $this->type; }

public function setType($type)

{ $this->type = $type; return $this; }

public function getValue()

{ return $this->value; }

public function setValue($value)

{ $this->value = $value; return $this; }

public function getClient()

{ return $this->client; }

public function setClient($client = null)

{ $this->client = $client; return $this; }

}

I also want to add: why don't Doctrine 2 just use the oracle "returning id into" statement, in this case regardless the identity mapping this will always return the inserted ID, and it will work with "AUTO", "SEQUENCE", "IDENTITY" and I think any other mapping word used!

I did try to trace where the problem come from, and it seems that when using OCI8 oracle driver that the invoked method is
Doctrine\ORM\Id\IdentityGenerator::generate
and it invokes
Doctrine\DBAL\Connection::lastInsertId
and is returning 0, I don't know why it is being invoked since the sequenceName is null (there is no sequence in the definition!)

Maybe a good solution is to check if the $statement is an 'INSERT INTO ' sql statement, then we bind an output variable to the statement which will hold the "returning ID into :output_variable" value... what do you think?



 Comments   
Comment by Mohammad A. ZeinEddin [ 20/Jul/13 ]

I am not professional in Doctrine, but I want to suggest something to get the last inserted id for Oracle... I think this is even better than using the sequence name to get it... and it works for all types of ID generation methods...!

I think a good solution will be to do something like this in the "Doctrine\DBAL\Driver\OCI8\OCI8Statement::__construct" (may be there is a better place or way, this is just a suggestion), and make it like the following:
1- first we check if the statement is an insert statement then we add a ' returning id into :lastInsertId' sql, here we need somehow to get the primary key column name, data type length (max_length) and make it dynamic, 'id' is just the PK in my case...
2- we bind the ':lastInsertId' parameter so that we can get it as output parameter.

here is a sample code, maybe it needs a lot of enhancement

public function __construct($dbh, $statement, OCI8Connection $conn)
{
list($statement, $paramMap) = self::convertPositionalToNamedPlaceholders($statement);
if (stripos($statement, 'INSERT INTO ') === 0) {
$statement = $statement . ' returning id into :lastInsertId';
}
$this->_sth = oci_parse($dbh, $statement);
$this->_dbh = $dbh;
$this->_paramMap = $paramMap;
$this->_conn = $conn;
if (stripos($statement, 'INSERT INTO ') === 0) {
oci_bind_by_name($this->_sth, ':lastInsertId', $this->lastInsertId, OCI_B_INT);
}
}

and then when executing (execute method) we will have $this->lastInsertId set for us and containing the last inserted id even if it is from a sequence... can you implement such thing? and by this the "http://docs.doctrine-project.org/en/latest/reference/basic-mapping.html#identifier-generation-strategies" Identifier Generation Strategies "IDENTITY" will work for oracle and will be full portable

Comment by Mohammad A. ZeinEddin [ 20/Jul/13 ]

I just attached the suggested changes in OCI8 diver files, I just need help with 2 TODO issues, and I think then all will be fine

Comment by Stanislav Ivanov [ 01/Oct/13 ]

I'm suggesting this is a bug and not an improvement as it leads to different ORM behavior when using different database drivers.

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

Unfortunately the approach you suggested won't work as we are not able to identify the PK to return from the insert statement on the fly.

Comment by Mohammad A. ZeinEddin [ 24/Nov/13 ]

can't we get the column/s name/s from the mapping in the OCI8Statement.php file? isn't there anyway to do that? can you suggest an approad to do that? because the retuning id into :var is the right way to do that in oracle for all types of mapping!

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

Sure basically your approach is the way to go but I don't see a way how to determine the column name to return the last insert id for. The driver does not know what the identity column for a particular insert statement is.

Comment by Stanislav Ivanov [ 25/Nov/13 ]

Steve, I disagree. Oracle last insert id should not rely on identity column, instead, it should rely on current sequence value. And this is properly implemented in OCI8Connection (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php, lastInsertId method).

Besides, the proper triggers are implemented in OraclePlatform (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/OraclePlatform.php).

As I see in OraclePlatform::getCreateAutoIncrementSql() method, the sequence name is like following:

$table . '_SEQ'

So, I think that the problem is that EntityManager (or some lower level) does not provide the proper sequence name to OCI8Connection::lastInsertId() method causing it to trigger this code:

if ($name === null) {
    return false;
}

Please, check if it helps. As for now Doctrine ORM is literally unusable with Oracle.

Comment by Stanislav Ivanov [ 25/Nov/13 ]

Okay, seems, I've found the way it is correctly done (I had predefined sequence name, don't now if it working for entity-based generated schema):

    /**
     * @var int
     *
     * @ORM\Column(name="id", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     * @ORM\SequenceGenerator(sequenceName="seq_mytable", initialValue=75)
     */
    private $id;

So, we're using SEQUENCE generated value strategy for Oracle automatically and we fall back to manually defined sequence generator.

Just run persist() and flush() and got correctly set newly generated id. So cool.

Comment by Mohammad A. ZeinEddin [ 25/Nov/13 ]

This does not work for us, we are generating IDs automatically based on some triggers, so sequenceName does not work in our case... the only thing that I found working is by the modifications suggested up in the files...

Comment by Stanislav Ivanov [ 25/Nov/13 ]

It surely has nothing to do with Oracle driver as custom id field can be generated using triggers on every database.

So, you need to implement your brand new generated value strategy as it does not comply with IDENTITY and SEQUENCE documentation. It would be a nice extension.

Maybe this could help: http://ranskills.wordpress.com/2011/05/26/how-to-add-a-custom-id-generation-strategy-to-doctrine-2-1

Comment by Mohammad A. ZeinEddin [ 25/Nov/13 ]

As you see here:
http://docs.doctrine-project.org/en/2.0.x/reference/basic-mapping.html#identifier-generation-strategies
the IDENTITY generation strategy is not implemented in Oracle... and I use it since the ID is generated bu the DB... so I think that it is better to change to the oracle way to get the last inserted ID when using this strategy...

Comment by Steve Müller [ 25/Nov/13 ]

IDENTITY generation strategy is SOMEHOW implemented in Oracle with the workaround of creating a (before insert) trigger on the specific table that uses a sequence to emulate an autoincrementation. I guess this is just a compatibility approach for IDENTITY strategy on a best effort basis and should not be relied on. This is also the reason why it is stated in the documentation as not fully portable. The issue discussed here is also not an issue of Doctrine ORM IMO as it is not responsible for evaluating if an IDENTITY strategy needs a sequence for the underlying driver to obtain the last insert ID. However there already seems to be hack for exactly the same case in PostgreSQL. See:

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L453

What we probaby COULD do is add another check in the ClassMetadataFactory for the Oracle platform to tell it to use a sequence for IDENTITY strategy. But that still is rather hackish to be honest...

Comment by Benjamin Eberlei [ 13/Dec/13 ]

Steve Müller The real issue is indeed, that IDENTITY is not really supported for Oracle. We would need to find a way to support it generically or throw an exception in the ORM if Oracle is used with IDENTITY.

Comment by Steve Müller [ 29/Dec/13 ]

Step one in fixing this issue has been applied in PR https://github.com/doctrine/dbal/pull/428 and fixed in commit https://github.com/doctrine/dbal/commit/d2845256d22a0ea2c5e5392aa67f4b95f252d5c4.
Step two has been supplied in ORM in PR https://github.com/doctrine/doctrine2/pull/890.

As soon as the PR on ORM side gets merged it is possible to use IDENTITY generator strategy with Oracle

Comment by Doctrine Bot [ 31/Dec/13 ]

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

Comment by Steve Müller [ 31/Dec/13 ]

Fixed in commits:
https://github.com/doctrine/dbal/commit/d2845256d22a0ea2c5e5392aa67f4b95f252d5c4
https://github.com/doctrine/doctrine2/commit/a7b9140d2fddcab995b2597be4d589155ff1aa8f





[DBAL-974] Escape Table Columns on Insert Created: 16/Aug/14  Updated: 18/Aug/14  Resolved: 18/Aug/14

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

Type: Bug Priority: Minor
Reporter: Andreas Möller Assignee: Steve Müller
Resolution: Can't Fix Votes: 0
Labels: None

Attachments: File ace_mag.sql    

 Description   

I use Doctrine to handle the following MySQL table (See attachment).
As you can see, the MySQL table has a column "by".

If you want to insert values by using the insert function of the Connection Class, an error appears:

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'by, bz, bt, lat, lon) VALUES ('2014-08-16 16:35:00', '0', '-2.3', '0.7', '-0.8',' at line 1' in ..

I used:

$entry = array(
  'date' => '2010-01-01 12:10:10',
  'status' => '0',
  'bx' => '0',
  'by' => '0',
  'bz' => '0',
  'bt' => '0',
  'lat' => '0',
  'lon' => '0',
);

$connection->insert($table, $entry);

The reason is, that Doctrine does not escape the "by" value. MySQL parses "by" as a statement.

False:

INSERT INTO solar.ace_mag (date, status, bx, by, bz, bt, lat, lon) VALUES ...

Correct:

INSERT INTO `solar`.`ace_mag` (`date`, `status`, `bx`, `by`, `bz`, `bt`, `lat`, `lon`) VALUES ...

I wrote the following helper function to escape my insert values-keys:

public static function prepareInsertValues(array $insertValues)
    {
        foreach ($insertValues as $key => $val) {
            $insertValues['`' . $key . '`'] = $val;
            unset($insertValues[$key]);
        }

        return $insertValues;
    }

PS: Maybe other function are effected (e.g. UPDATE,...)



 Comments   
Comment by Steve Müller [ 18/Aug/14 ]

Andreas Möller this is a known issue we cannot fix in a reliable way. The Connection API is not intended to consume user input data because of possible SQL injection vulnerabilities. Escaping identifiers is not as easy as it might seem at the first glance and your provided helper function does only escape "clean" identifiers which do not contain the escape character or even SQL injection code. For further information please have a look here:

http://www.doctrine-project.org/2014/02/21/security_in_doctrine.html





[DBAL-973] [GH-661] Added field specific options for converting data between PHP and DB Created: 15/Aug/14  Updated: 15/Aug/14  Resolved: 15/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: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Added option parameter so field specific data can be passed when converting data for types. This is needed in cases like enum types or more generic types where you want field specific options for conversion.

This would give developers more freedom in creating custom domain-specific types.

Our (simplified) use-case is:
```php
class EnumType extends Type
{
const ENUM = 'enum';

public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform)

{ return 'Enum'; }

public function convertToPHPValue($value, AbstractPlatform $platform, array $options = [])

{ return (null === $value) ? null : new $options['class']((int) $value); }

public function convertToDatabaseValue($value, AbstractPlatform $platform, array $options = [])

{ return $value; }

public function getName()

{ return self::ENUM; }

}
```
This way you can define a generic Enum and configure the matching type of the enum in the field itself. The end goal is to make use of this change in the ORM as follows:
```php
class Entity
{
/**

  • @ORM\Column(
  • name = "bar",
  • type = "enum",
  • type_options = { * "class" = "\Foo\Bar\FooBarEnum" * }
  • )
  • @var FooBarEnum
    */
    private $foo;
    }
    ```


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

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

Comment by Doctrine Bot [ 15/Aug/14 ]

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





[DBAL-972] [GH-660] Fix rst list Created: 12/Aug/14  Updated: 13/Aug/14  Resolved: 13/Aug/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: None


 Description   

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

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

Message:

The current version is not displayed correctly at
http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/portability.html



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/83f92c3f28e927917ddcb7cf214ce99c0b72004b





[DBAL-971] [GH-659] Improve QueryBuilder docs Created: 12/Aug/14  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Documentation 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/659

Message:

  • Remove aliases from examples where they make no sense
  • Fixed copy paste error


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

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

Comment by Doctrine Bot [ 12/Aug/14 ]

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





[DBAL-630] Incorrect PostgreSQL boolean handling Created: 14/Oct/13  Updated: 12/Aug/14  Resolved: 12/Aug/14

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

Type: Bug Priority: Critical
Reporter: Stan Imbt Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This is a follow-up to issue #457 ("Use int values instead of strings for PostgreSQL booleans"), which is still not fixed. Int values are no solution at all. In fact the root cause lies deeper, outside the PostgreSQL platform class.

1. The patch to fix #457 does not change the default behaviour of the PostgreSQL platform class (method convertBooleans() returns strings 'true'/'false'). When the PostgreSQL PDO driver is configured to emulate prepared statements, it still results in unexpected failures, storing boolean false entity values as true in the database.

2. The new alternative boolean conversion mode activated by PostgreSqlPlatform::setUseBooleanTrueFalseStrings(false) is of no use as it prevents execution of DQL queries with boolean conditions, because integers 0 and 1 are not valid boolean literals in PostgreSQL.

The root cause is the notion of a PHP value being convertible to a database value. Because in fact there are two different types of "database values":

  • Literals used directly in SQL statements
  • Values passed as parameters to prepared statements

To make this absolutely clear:

Prerequisites
$pdo = new PDO(...);
$pdo->exec('CREATE TABLE my_table(bool_col BOOLEAN NOT NULL)');
$stmt = $pdo->prepare('INSERT INTO my_table(bool_col) VALUES(?)');
Using string 'false'
$value = 'false';

// This works, using the SQL literal false
$pdo->exec('INSERT INTO my_table(bool_col) VALUES(' . $value . ')');

// This works, too. But it's remarkable that Postgres accepts the string 'false'
// as a boolean value. Compare this to the string 'NULL' in an SQL statement vs.
// 'NULL' as a prepared statement param (instead of PHP null).
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

// Sets bool_col to true! The PostgreSQL PDO driver correctly expects a boolean
// and (string)'false' yields true.
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();
Using boolean false
$value = false;

// This will obviously fail, because false is cast to an empty string, resulting
// in "... VALUES()".
$pdo->exec('INSERT INTO my_table(bool_col) VALUES(' . $value . ')');

// Works
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

// Works, too
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();
Using integer 0
$value = 0;

// Causes 'ERROR: column "bool_col" is of type boolean but expression is of type integer'
$pdo->exec('INSERT INTO my_table(bool_col) VALUES(' . $value . ')');

// Works
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

// Works, because of implicit PHP type cast 0 -> false
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$stmt->bindValue(1, $value, PDO::PARAM_BOOL);
$stmt->execute();

There are two locations in DBAL and ORM where AbstractPlatform::convertBooleans() is called to build SQL literals:

DoctrineDBALPlatformsAbstractPlatform::getDefaultValueDeclarationSQL()
$default = " DEFAULT '" . $this->convertBooleans($field['default']) . "'";

Wow, this is even being enclosed in single quotes!? But then the whole method is buggy anyway, e.g. using an unescaped string value for a string literal (scenarios for SQL injection unlikely but possible).

DoctrineORMQuerySqlWalker::walkLiteral()
case AST\Literal::BOOLEAN:
	$bool = strtolower($literal->value) == 'true' ? true : false;
	$boolVal = $this->conn->getDatabasePlatform()->convertBooleans($bool);
	return $boolVal;

...and the result is later used as a boolean literal in an SQL query.

To solve this we need something like AbstractPlatform::convertBoolToSqlLiteral() (returning strings true and false for the Postgres platform) and AbstractPlatform::convertBoolToDbValue() (converting to integer 0 or 1 for platforms without a native bool type).

Note 1: The docs currently suggest to call $conn->getDatabasePlatform()->setUseBooleanTrueFalseStrings($flag). This is bad OO design, because getDatabasePlatform() returns an AbstracPlattform instance which does not have a contract for the method.

Note 2: What makes this problem so nasty is the fact that switching to emulated prepares makes an application fail in a non-obvious way. There will be no traceable errors but simply all boolean false values in ORM entities stored as boolean true. When integration tests use a different database (e.g. an SQLite in-memory DB to minimize test execution time) the problem will even escape the tests. And the distance between cause and effect also makes the problem very hard to find. Who would expect a database driver setting to cause booleans in the DB to be the opposite of what they're supposed to be? Especially as this only becomes apparent after later re-hydrating stored entities.

Note 3: Why emulated prepared statements matter: When PostgreSQL processes a prepared statement, its query planner works out a query plan and uses it for all subsequent executions of this query. This way it has to make a rather crude guess at the number of affected rows from each table in a join. When a non-prepared query is executed, the query planner can take into account the given values (mostly the ones in the "WHERE" part of the query) and make a much more specific guess at which plan will perform best.
In our case, we decided to switch to emulated prepares after we found out that a complex query in our application would run five times faster with emulated prepares.

Note 4: Is there a reason for AbstractPlatform::convertBooleans() accepting either a single bool value or an array of bool values? I didn't find client code calling it with an array. This makes the method less obvious, is currently implemented with code duplication and at least for the PostgreSQL plattform class, the "array of bool" functionality is not even tested.



 Comments   
Comment by Benjamin Eberlei [ 01/Jan/14 ]

PDO::ATTR_EMULATE_PREPARES finally explains why I was unable to reproduce this before. This is obviously a very critical error. Increasing priority.

Comment by Benjamin Eberlei [ 01/Jan/14 ]

Stan Imbt I cannot really reproduce the ATTR_EMULATE_PREPARES issue, see https://github.com/doctrine/dbal/commit/f29f0fae8479955911928888ebab07ccd4e8ab0c

I agree that we need two methods on the Platform for casting values to SqlLiterals and to Params, as they are in two different contexts.

Comment by Benjamin Eberlei [ 01/Jan/14 ]

We have a reproduce-case, it fails on Travis: https://travis-ci.org/doctrine/dbal/jobs/16217622

Comment by Stan Imbt [ 02/Jan/14 ]

Thanks for looking into this, Benjamin.
We could reproduce the problem with different PHP 5.4 builds on both Linux and Windows (Postgres version shouldn't matter as emulated prepares are handled in the Postgres PDO driver). Travis runs the tests on PHP 5.3 and also fails as expected. Are you using PHP 5.5? If so, I assume the PHP folks have recently changed the PG PDO driver's behaviour, making it act more like PG itself (i.e. converting a bool param with string value 'false' to boolean false).

Comment by Davi Koscianski Vidal [ 31/Mar/14 ]

I'm using PHP 5.5.3 + PostgreSQL 9.3.3 and I confirm that this is not working.

But it looks like it won't work for anyone because PHP: https://bugs.php.net/bug.php?id=57157.

Comment by Stan Imbt [ 01/Apr/14 ]

Davi, I can reproduce the referenced PHP bug, both with and without emulated prepares, but it is not related to this Doctrine bug.

Doctrine calls PDOStatement::bindValue(), specifying the data type PDO::PARAM_BOOL in case of bool fields. The PHP bug only occurs when the param data type is not provided, apparently converting the param value to string ((string)false === '') and passing that on to the DBMS.

Comment by Davi Koscianski Vidal [ 01/Apr/14 ]

Stan, almost the same 'test case' as PHP bug:

<?php

/*
CREATE TABLE "booleantest" (
  "persistence_object_identifier" serial NOT NULL,
  "hidden" boolean NOT NULL
);
 */

$handle = new PDO('pgsql:host=127.0.0.1 dbname=postgres', 'postgres', 'postgres');
$handle->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$handle->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$handle->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$handle->setAttribute(PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT, true);

$statement = $handle->prepare('INSERT INTO booleantest (hidden) VALUES (?)');

// works as expected
$statement->execute(array(true));
echo 'TRUE has been inserted' . PHP_EOL;

$statement->bindValue(1, "true", PDO::PARAM_BOOL);
echo 'TRUE has been inserted' . PHP_EOL;

// dies with
// PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: ""
// $statement->execute(array(FALSE));

$statement->bindValue(1, "false", PDO::PARAM_BOOL);
$statement->debugDumpParams();
$statement->execute();
echo 'FALSE has been inserted' . PHP_EOL;

When PDO::ATTR_EMULATE_PREPARES is set to true, $stmt->debugDumpParams() outputs:

SQL: [43] INSERT INTO booleantest (hidden) VALUES (?)
Params:  1
Key: Position #0:
paramno=0
name=[0] ""
is_param=1
param_type=2

But when it is disabled, it outputs:

SQL: [43] INSERT INTO booleantest (hidden) VALUES (?)
Params:  1
Key: Position #0:
paramno=0
name=[0] ""
is_param=1
param_type=5

This is exactly the same output from tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php (after adding debugDumpParam() to DBAL\Driver\PDOStatement.php, obviously). param_type = 2 when type = PDO::PARAM_STR.
For debugging purposes, I changed DBAL\Driver\PDOStatement.php line 67 from return parent::bindValue($param, $value, $type); to parent::bindValue(1, "false", \PDO::PARAM_BOOL); (so I will always store a boolean false on database), but debugDumpParam() keeps telling me that param_type is 2 if I'm using emulated prepares.

Comment by Davi Koscianski Vidal [ 01/Apr/14 ]

Using $stmt->bindValue(1, 'false', \PDO::PARAM_STR); works as expected. Maybe a dirty workaround?

Comment by Davi Koscianski Vidal [ 03/Apr/14 ]

This same test case passes with PHP 5.3.18, but fails with 5.5.3 and 5.5.11.

$ phpenv shell 5.5.11

$ php --version
PHP 5.5.11 (cli) (built: Apr  3 2014 09:52:27) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies

$ vendor/bin/phpunit -c postgres.phpunit.xml tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php 
PHPUnit 3.7.34 by Sebastian Bergmann.

Configuration read from.postgres.phpunit.xml

..F

Time: 3.91 seconds, Memory: 4.25Mb

There was 1 failure:

1) Doctrine\Tests\DBAL\Functional\Ticket\DBAL630Test::testBooleanConversionBoolParamEmulatedPrepares
Failed asserting that true is false.

./tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php:79

FAILURES!
Tests: 3, Assertions: 6, Failures: 1.

$ phpenv shell system 

$ php --version
PHP 5.5.3-1ubuntu2.2 (cli) (built: Feb 28 2014 20:06:05) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
    with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend Technologies

$ vendor/bin/phpunit -c postgres.phpunit.xml tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php 
PHPUnit 3.7.34 by Sebastian Bergmann.

Configuration read from ./postgres.phpunit.xml

..F

Time: 1.59 seconds, Memory: 4.25Mb

There was 1 failure:

1) Doctrine\Tests\DBAL\Functional\Ticket\DBAL630Test::testBooleanConversionBoolParamEmulatedPrepares
Failed asserting that true is false.

./tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php:79

FAILURES!
Tests: 3, Assertions: 6, Failures: 1.

$ phpenv shell 5.3.18 

$ php --version
PHP 5.3.18 (cli) (built: Apr  2 2014 16:47:04) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

$ vendor/bin/phpunit -c postgres.phpunit.xml tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL630Test.php 
PHPUnit 3.7.34 by Sebastian Bergmann.

Configuration read from ./postgres.phpunit.xml

...

Time: 1.06 seconds, Memory: 6.50Mb

OK (3 tests, 6 assertions)
Comment by Davi Koscianski Vidal [ 04/Apr/14 ]

I think I messed something when creating the PR. The bot automatically created this ticket: http://www.doctrine-project.org/jira/browse/DBAL-863

I'm sorry.

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

Fixed in PR: https://github.com/doctrine/dbal/pull/625
Commit: https://github.com/doctrine/dbal/commit/5eb36c7a643d5e44f0eee4ca39e56088527ce146





[DBAL-970] Implement partial indexes for missing platforms Created: 12/Aug/14  Updated: 12/Aug/14

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

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


 Description   

As a follow-up to DBAL-900 there are some platforms left that support partial indexes too and need the implementation for that feature.
Currently partial indexes are only implemented for PostgreSQL.
Additionally there should be a functional test covering creation and introspection of partial indexes if possible.






[DBAL-969] [GH-658] DBAL-968 Created: 11/Aug/14  Updated: 11/Aug/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 zeroedin-bill:

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

Message:

The recent change to SQLServerPlatform.php (https://github.com/doctrine/dbal/commit/17dad30dc9acd91a5cda0da2c5ce2c40d522f766) broke the ORM Paginator's queries on SQL server.

I investigated, and found that some of the test cases for the SQL Server platform weren't actually correct SQL. Also, there were no test cases that covered what the paginator is doing, so I've written test cases for those. I will open a pull request for this issue.

The modifyLimitQuery method in SQLServerPlatform.php should be fixed to pass the fixed old tests and the new tests.

My concern is that that method is becoming too complex, but that's an issue for another day.






[DBAL-968] SQL Server modifyLimitQuery broken Created: 11/Aug/14  Updated: 11/Aug/14

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

Type: Bug Priority: Critical
Reporter: William Schaller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator, sqlserver
Environment:

SQL Server



 Description   

The recent change to SQLServerPlatform.php @jaylinski:improved sqlserver 'doModifyLimitQuery' select-from pattern broke the ORM Paginator's queries on SQL server.

I investigated, and found that some of the test cases for the SQL Server platform weren't actually correct SQL. Also, there were no test cases that covered what the paginator is doing, so I've written test cases for those. I will open a pull request for this issue.

The modifyLimitQuery method in SQLServerPlatform.php should be fixed to pass the fixed old tests and the new tests.

My concern is that that method is becoming too complex, but that's an issue for another day.



 Comments   
Comment by Marco Pivetta [ 11/Aug/14 ]

I'm gonna cry. Thank you, MSSQL, you make our lives so much "easier"





[DBAL-967] [GH-656] allow nested functions as second parameter to DATE_* functions Created: 06/Aug/14  Updated: 10/Aug/14  Resolved: 10/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: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

Using sqlite as backend you can't pass nested function for the second parameter of DATE_* functions since it is transformed to a string. I've fixed that concatenating the string expression passed to sqlite DATE and DATETIME function using the getConcatExpression method - does this seem correct?

The DATE_* functions work fine with nested second parameter in mysql.

I've added assertions similar to other platforms for the date functions.



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

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





[DBAL-949] [GH-636] Update SQLSrvStatement.php Created: 22/Jul/14  Updated: 08/Aug/14  Resolved: 08/Aug/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 bouland:

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

Message:

I would like to extends functionnality of the driver.

Feel free to explain me if there is better pattern to add behavior.
May be getters and setters ?

I m using DBAL in Symfony 2.

I would like to add specific functionnality and re use DBAL connection.



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

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





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

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

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

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

 Description   

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

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



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

This was fixed in 2.3.3

Comment by Joseph Wynn [ 06/Aug/14 ]

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

Comment by Joseph Wynn [ 06/Aug/14 ]

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

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Marco Pivetta [ 06/Aug/14 ]

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

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

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





[DBAL-451] [GH-276] DBAL-446 Created: 19/Feb/13  Updated: 06/Aug/14  Resolved: 06/Apr/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

Fix for DBAL-446 with a proper test case and two general test cases.



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

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

Comment by Doctrine Bot [ 06/Aug/14 ]

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





[DBAL-966] [GH-655] json_array columns should return null for null values Created: 06/Aug/14  Updated: 06/Aug/14  Resolved: 06/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: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-446 Type json_array can't be null Reopened

 Description   

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

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

Message:

I guess this is a BC-break, but it fixes DBAL-446(http://www.doctrine-project.org/jira/browse/DBAL-446).



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

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

Comment by Marco Pivetta [ 06/Aug/14 ]

Fix cannot land in 2.x

Comment by Doctrine Bot [ 06/Aug/14 ]

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





[DBAL-965] [GH-654] doModifyLimitQuery() was missing an outer "ORDER BY doctrine_rownum" Created: 06/Aug/14  Updated: 06/Aug/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






[DBAL-964] [GH-653] Update docs to include warning when using object type with PostgreSQL Created: 05/Aug/14  Updated: 05/Aug/14  Resolved: 05/Aug/14

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

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

Issue Links:
Reference
is referenced by DDC-3241 object type fails to save serialized ... Open

 Description   

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

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

Message:

Follow up to: http://www.doctrine-project.org/jira/browse/DDC-3241



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

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





[DBAL-959] [GH-648] Allow to get bound parameter types from query builder. Created: 04/Aug/14  Updated: 04/Aug/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 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





[DBAL-960] [GH-649] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test



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

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Marco Pivetta [ 04/Aug/14 ]

Wrong merge origin/target branches





[DBAL-961] [GH-650] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test.



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

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

Comment by Marco Pivetta [ 04/Aug/14 ]

wrong target/origin branches





[DBAL-962] [GH-651] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test.



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

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

Comment by Marco Pivetta [ 04/Aug/14 ]

PR was opened with wrong merge origin/target





[DBAL-963] [GH-652] Add close() method in MasterSlaveConnection.php Created: 04/Aug/14  Updated: 04/Aug/14  Resolved: 04/Aug/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
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


 Description   

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

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

Message:

MasterSlaveConnection would use parent::close() to close connection, and it would close master connection, but slave connection.

That will increase the sqlite connections, and occur the "too many open files" error when I run our test.



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

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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





[DBAL-958] [GH-647] Update docs to relfect the changes to QueryBuilder::from made in #646 Created: 01/Aug/14  Updated: 01/Aug/14  Resolved: 01/Aug/14

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

Type: Documentation 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 JeroenDeDauw:

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

Message:



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

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

Comment by Doctrine Bot [ 01/Aug/14 ]

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





[DBAL-957] [GH-646] Make the $alias parameter in the `from` method optional Created: 31/Jul/14  Updated: 01/Aug/14  Resolved: 01/Aug/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 JeroenDeDauw:

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

Message:

The refactoring commits can be merged first using PR #645



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

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

Comment by Doctrine Bot [ 01/Aug/14 ]

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





[DBAL-956] [GH-645] Improvements to QueryBuilder Created: 31/Jul/14  Updated: 31/Jul/14  Resolved: 31/Jul/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: Incomplete 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/645

Message:



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

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





[DBAL-889] [GH-590] Add a select method to Connection Created: 30/Apr/14  Updated: 31/Jul/14  Resolved: 31/Jul/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 JeroenDeDauw:

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

Message:

This is a draft; it has not been tested, not even manually.
It is meant for conceptual review



 Comments   
Comment by Doctrine Bot [ 30/Apr/14 ]

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

Comment by Doctrine Bot [ 30/Apr/14 ]

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

Comment by Doctrine Bot [ 31/Jul/14 ]

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





[DBAL-955] No exception thrown for query error Created: 31/Jul/14  Updated: 31/Jul/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?





[DBAL-954] Custom QuoteStrategy doesn't work when creating new schema Created: 30/Jul/14  Updated: 30/Jul/14

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

Type: Bug Priority: Minor
Reporter: Piotr Łyczba Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool


 Description   

Implementing custom quote strategy:

class SingleQuoteStrategy extends DefaultQuoteStrategy implements QuoteStrategy
{
    public function getColumnName($fieldName, ClassMetadata $class, AbstractPlatform $platform)
    {
        return isset($class->fieldMappings[$fieldName]['quoted'])
            ? $platform->quoteSingleIdentifier($class->fieldMappings[$fieldName]['columnName'])
            : $class->fieldMappings[$fieldName]['columnName'];
    }
}

doesn't work when a new schema is created.

The problem is that in class file mapping I have column that has dot in its name escaped with back single quotes:

<field name="anuncianteId_delete" type="integer" column="`anunciante_id.delete`" nullable="true"/>

My custom quote strategy is necessary to force Doctrine to respect that. Otherwise Doctrine treats it as: namespace.name.

If I already have table with that column in my database update schema tool doesn't complains, the problem occurs only when I try to create new schema.

The error in resulting SQL Statement:

(SQLSTATE[HY000]: General error: 1 near ".": syntax error' while executing DDL: CREATE TABLE account ( (...) "anunciante_id"."delete" INTEGER DEFAULT NULL, (...) )





[DBAL-950] [GH-637] Backport #625 - pgsql boolean conversion Created: 22/Jul/14  Updated: 29/Jul/14  Resolved: 29/Jul/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
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


 Description   

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

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

Message:



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

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





[DBAL-539] [GH-332] [DDC-2470] Use column name instead of alias to modify order by clause Created: 05/Jun/13  Updated: 28/Jul/14  Resolved: 07/Jun/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
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 FabioBatSilva:

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2470



 Comments   
Comment by Doctrine Bot [ 07/Jun/13 ]

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

Comment by Fabio B. Silva [ 07/Jun/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/753d63c2d48facdecba5d84f6ed2450024de2867

Comment by Doctrine Bot [ 28/Jul/14 ]

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





[DBAL-537] [GH-330] Cloning Created: 04/Jun/13  Updated: 27/Jul/14  Resolved: 18/Jun/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 DDC-2313 Deep clone for DBAL QueryBuilder Resolved

 Description   

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

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

Message:

This adds deep clone support to the DBAL QueryBuilder. I just realized, there is already a pending pull request for this, however, this one already incorporates the suggestions found in the former.



 Comments   
Comment by Doctrine Bot [ 18/Jun/13 ]

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

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DBAL-535] [GH-328] Added PostgreSQL schemas creation Created: 31/May/13  Updated: 27/Jul/14  Resolved: 08/Aug/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 maxim-styushin:

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

Message:

When doing doctrine:schema:create it puts tables only in public schema and can't create any other. Trying to specify other schema like schema_name.table_name causes an error. This patch solved it for me.



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

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

Comment by Fabio B. Silva [ 08/Aug/13 ]

Closed, For more details see https://github.com/doctrine/dbal/pull/328

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DBAL-536] [GH-329] Add method ResultStatement::rowCount() Created: 01/Jun/13  Updated: 27/Jul/14  Resolved: 10/Aug/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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Sometimes it is required to get the number of rows in a result before
fetching the data itself. PDO provide PDO_Statement::rowCount() for
this, wich is now be added to the ResultStatement interface.
This will only affect the class ArrayStatement, because it is the only
statement implementation, that does not provide rowCount().



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

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

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DBAL-953] [GH-643] Split the methods in TestUtil more and improve naming Created: 27/Jul/14  Updated: 27/Jul/14  Resolved: 27/Jul/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 JeroenDeDauw:

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

Message:



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

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





[DBAL-952] [GH-642] foreach AS -> foreach as Created: 27/Jul/14  Updated: 27/Jul/14  Resolved: 27/Jul/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 JeroenDeDauw:

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

Message:



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

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





[DBAL-951] [GH-641] Remove duplicate suggest section in composer.json Created: 27/Jul/14  Updated: 27/Jul/14  Resolved: 27/Jul/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
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


 Description   

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

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

Message:

As per comment on 047abd4d8dbe16b5d3bd7d2dd8cc475ec674dd74



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

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





[DBAL-932] [GH-627] Fix escaping of column name for specific alter table case Created: 01/Jul/14  Updated: 22/Jul/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 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





[DBAL-948] [GH-635] Update SQLSrvStatement.php Created: 22/Jul/14  Updated: 22/Jul/14  Resolved: 22/Jul/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
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: None


 Description   

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

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

Message:

Hi,

I would like to exec a stored procedure with multi result so I think i need that :
http://msdn.microsoft.com/en-us/library/cc296167(v=sql.105).aspx

Is it possible to add specific behavior in general DBAL ?
It is my first pull request, feel free to explain me where I m doing wrong.

Rgds,
Simon



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

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

Comment by Marco Pivetta [ 22/Jul/14 ]

This feature can't be provided as it is very platform specific





[DBAL-947] [GH-634] Transaction object definition Created: 21/Jul/14  Updated: 21/Jul/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 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-927] [GH-622] improved sqlserver 'doModifyLimitQuery' select-from pattern Created: 23/Jun/14  Updated: 21/Jul/14  Resolved: 21/Jul/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-940 ORDER BY with LIMIT in SQL Server doe... Open

 Description   

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

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

Message:

the current regex-pattern in the `doModifyLimitQuery`-function is very slow and buggy for my sqlserver queries.
i think the slowness is a result from the atomic-group inside the regex.

I tried to improve it, but since I'm not an regex-expert at all, I don't know if the 'fix' satisfies all needs.
the unit-tests returned ok.

it would be perfect if someone with some regex-knowledge would have a look at this before merging it.



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

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





[DBAL-946] Array type with non ascii chars Created: 21/Jul/14  Updated: 21/Jul/14  Resolved: 21/Jul/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: Саша Стаменковић Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This is the result I get in database "a:48:{s:8:"distance";s:2:"37";s:9:"Reykjav" after persisting array with value Reykjavík.

As you can see, it is cut on í letter.



 Comments   
Comment by Саша Стаменковић [ 21/Jul/14 ]

I cant post code to reproduce this issues, looks like response I get from API have some strange encoding.

Comment by Marco Pivetta [ 21/Jul/14 ]

The values are likely truncated because of the db-side encoding.

Marking as invalid unless there's a test case to reproduce the issue with utf-8 encoding.





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

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

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

db2 v10.5 centos 6.5 64



 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





[DBAL-945] [GH-633] Db2altercolumnsyntaxbug Created: 20/Jul/14  Updated: 20/Jul/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 rehfeldchris:

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

Message:

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






[DBAL-943] dbal db2 platform uses incorrect column modification strategy for clob Created: 20/Jul/14  Updated: 20/Jul/14

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

Type: Bug Priority: Critical
Reporter: chris rehfeld Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

db2 v10.5 centos 6.5



 Description   

db2 only allows certain column types to be used in an ALTER TABLE ALTER COLUMN myCol ... type statement.

Example entity

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

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

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

If you then change the column type from string to text via ...

Widget2.php
    /** @ORM\Column(type="text") **/
    private $str;

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

ALTER TABLE WIDGET2 ALTER STR str CLOB(1M) NOT NULL;

The sql syntax is wrong, but that's a different issue I'll address elsewhere.Lets assume it's fixed to be proper syntax:
ALTER TABLE WIDGET2 ALTER COLUMN str SET DATA TYPE CLOB(1M) ALTER COLUMN str SET NOT NULL;

This triggers sql error code -190, sqlstate 42837
http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.codes/src/tpc/n190.dita

Because the from type => to type isn't valid. This link:
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.1.0/com.ibm.db2.udb.admin.doc/doc/r0000888.htm?lang=en
seems to list the valid alterations.

I'm guessing that a different strategy needs to be used; where we drop the old column, and create the new one in such scenarios. This could cause unexpected data loss though.






[DBAL-939] schema update doesnt detect boolean type correctly Created: 16/Jul/14  Updated: 20/Jul/14

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

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

centos 6 64, db2 luw10.5



 Description   

*edited*

Dbal for db2 doesn't seem to be able to differentiate between a smallint and a boolean field on db2. If I make an entity which has a boolean field, it will create a table using type smallint. If I later try to update the schema, it will detect the column in the table as a small int, not a boolean. So, it will produce sql update statements to change the type from smallint to smallint, which is obviously unnecessary. I understand db2 doesn't have a boolean type, but it would be nice if dbal realized that a smallint is essentially already a dbal boolean.

Additionally, the update statement is invalid syntax and fails, although this is probably a separate issue.

Example entity

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

    /** @ORM\Column(type="boolean", nullable=false) **/
    private $isGoat;
}

orm:schema-tool:create produces:
CREATE TABLE Widget (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, isGoat SMALLINT NOT NULL, PRIMARY KEY(id));

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

ALTER TABLE WIDGET ALTER ISGOAT isGoat SMALLINT NOT NULL; CALL SYSPROC.ADMIN_CMD ('REORG TABLE WIDGET');

but no column alteration is obviosuly needed.

So in summary, smallint to boolean type mapping isn't realized, causing the update command to think it needs to change the type of the column.






[DBAL-942] [GH-632] Add test to verify null cast in boolean type Created: 18/Jul/14  Updated: 18/Jul/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 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```






[DBAL-941] [GH-631] updated PDO_SQLSRV connection to use driverOptions in prepare-function Created: 18/Jul/14  Updated: 18/Jul/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 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.






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

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

Type: Bug Priority: Major
Reporter: M.K. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
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





[DBAL-938] [GH-630] How to handle the join operations within different databases? Created: 12/Jul/14  Updated: 12/Jul/14  Resolved: 12/Jul/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


 Description   

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

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

Message:

I'm handling something about sharding recently. What I want to do is to add more machines or nodes to my system so that storing more data is possibale, or scale-out.

I found many people add a middle layer between their applications and databases, mysql for example. That seems to be perfect for me at first glance. But then I'm puzzled about the query and join operation.

Q1:
How to handle queries with offset and limit like:
'select * from xxxx where yyyy order by col_a asc limit num_b, num_c'
Just perform the query 'select * from xxxx where yyyy order by col_a asc limit 0, num_b + num_c' on each machine, merge the results and return [num_b, num_b + num_c)?
Q2:
How to handle the join operations within different databases?

Currently, I'm trying to solve the first problem by merging the results on the middle layer. There comes another tough problem. That is to reduce the memory usage. Working on, and suggestions are welcome~






[DBAL-937] Make fieldDeclaration available in getName method of class Type Created: 11/Jul/14  Updated: 11/Jul/14

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

Type: New Feature Priority: Major
Reporter: Dominic Tubach Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I've created a custom type that stores its data in a VARCHAR field. As requiresSQLCommentHint() returns true the value returned by getName() is used as type hint. If I change the length of the field in the entity mapping the scheme won't be updated because getName() still returns the same string. Now I would like to add the length to the returned string. Because this requires access to the fieldDeclaration I suggest to pass this array as paramater to getName().






[DBAL-936] Doctrine type not found exception thrown before checking the comment Created: 10/Jul/14  Updated: 11/Jul/14

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

Type: Bug Priority: Major
Reporter: Maxime Veber Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, mysql


 Description   

Here is the piece of code:

$type = $this->_platform->getDoctrineTypeMapping($dbType);

// In cases where not connected to a database DESCRIBE $table does not return 'Comment'
if (isset($tableColumn['comment'])) {
    $type = $this->extractDoctrineTypeFromComment($tableColumn['comment'], $type);
    $tableColumn['comment'] = $this->removeDoctrineTypeFromComment($tableColumn['comment'], $type);
}

The method `getDoctrineTypeMapping` throw an exception if the type is not found. But for example if you have an enum type (see the doctrine cookbook on the subject), the type is setted as comment.

Doctrine throw the exception before having the occasion to get the type via comment.

Here are two solutions:

  • Check for comment before throw the exception
  • Adding the enum type to the doctrine platform and mapping it to string





[DBAL-935] [GH-629] Allow to connect without a dbname param Created: 08/Jul/14  Updated: 08/Jul/14  Resolved: 08/Jul/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 mikeSimonson:

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

Message:

The PDO connection allow the instantiation of the connection even if the dbname
parameter isn't present. This change is there to make sure both behave the same way.



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

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

Comment by Marco Pivetta [ 08/Jul/14 ]

Merged: https://github.com/doctrine/dbal/commit/8cbfefe03ff2d1a2246dfb6e98b84e4b36622e6f





[DBAL-887] [GH-588] Don't return the return values of methods that do not return anything Created: 29/Apr/14  Updated: 06/Jul/14  Resolved: 29/Apr/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: Guilherme Blanco
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/588

Message:



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

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DBAL-933] Get Statement Column Metadata Created: 05/Jul/14  Updated: 06/Jul/14

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

Type: New Feature Priority: Trivial
Reporter: Benoît Burnichon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be nice to have a utility method in \Doctrine\Dbal\Driver\ResultStatement to properly retrieve the result column names.

Currently, we have to rely on somthing like
$columnNames = array_keys($statement->fetch(\PDO::FETCH_ASSOC));

Problem: It does not work with empty result-sets, and more checks should be performed to handle these.

With PDO, http://www.php.net/manual/en/pdostatement.getcolumnmeta.php could be used to properly retrieve names.

For Sqlite3 it is easy, http://www.php.net/manual/en/sqlite3result.columnname.php

For Mysql, http://www.php.net/manual/en/mysqli-result.fetch-fields.php would do the trick






[DBAL-934] [GH-628] bug fix for db2 v10 new column def of syscat.columns.default Created: 05/Jul/14  Updated: 05/Jul/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 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-662] Supporting PHP 5.5 DateTimeImmutable Created: 14/Nov/13  Updated: 02/Jul/14

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

Type: New Feature Priority: Minor
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: mapping, schematool


 Description   

Introducing new types converting dates into a DateTimeImmutable rather than a DateTime could be useful for applications prefering the use of immutable datetimes (and relying on PHP 5.5+).

The existing types already support setting a DateTimeImmutable in a field mapped with the datetime type, as it does not check the value against DateTime but only expects a format method. but the conversion from DB to PHP will always produce a mutable DateTime instance, thus preventing to use the immutable flavour consistently.

Not that this is a low priority issue as any code interacting with third party packages will probably need to use DateTime anyway because of the typehints (typehinting DateTimeInterface would not work if you need to keep compatibility with 5.4)

If DBAL 3.0 bumps the minimal supported version to 5.5 (which might be possible depending of the release date of 3.0), we could decide to break BC and use the immutable flavour in the datetime type directly.



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

Christophe Coevoet Should we mark that for 3.0 as suggested? Or do you see any need/possibility of implementing this already in 2.x branch?

Comment by Yaroslav Nechaev [ 02/Jul/14 ]

Please add this feature. Mutable DateTime causes too much trouble: now we have to use clone in every getter and setter just in case someone modifies the value afterwards and spoils the value stored in entity.

Comment by Steve Müller [ 02/Jul/14 ]

Yaroslav Nechaev I don't think we can support this before Doctrine 3.0 without breaking BC as Christophe Coevoet already stated because it would require us to bump the minimal supported PHP version to 5.5 (which currently is 5.3.2).





[DBAL-863] [GH-564] [DBAL-630] Incorrect PostgreSQL boolean handling Created: 04/Apr/14  Updated: 30/Jun/14  Resolved: 27/Jun/14

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

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: boolean, dbal, orm, postgresql

Issue Links:
Reference
relates to DBAL-931 pgSql boolean conversion Resolved

 Description   

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

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

Message:

Working on PostgreSQL incorrect boolean handling when emulating prepared statements



 Comments   
Comment by Davi Koscianski Vidal [ 04/Apr/14 ]

This PR is related to http://www.doctrine-project.org/jira/browse/DBAL-630

Comment by Davi Koscianski Vidal [ 04/Apr/14 ]

The only issue with this PR is that it breaks Doctrine2 ORM. I already have a patch for that too, but I'm not sure on how to proceed.

Comment by Davi Koscianski Vidal [ 04/Apr/14 ]

I'm not breaking ORM anymore.

Comment by Doctrine Bot [ 27/Jun/14 ]

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

Comment by Marco Pivetta [ 27/Jun/14 ]

Moved to PR https://github.com/doctrine/dbal/pull/625

Comment by Doctrine Bot [ 30/Jun/14 ]

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





[DBAL-811] [GH-527] Birko boolean conversion Created: 12/Feb/14  Updated: 30/Jun/14  Resolved: 30/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: Incomplete Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-931 pgSql boolean conversion Resolved

 Description   

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

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

Message:

Added platform specific conversion form database Boolean type to PHP bool type



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

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

Comment by Marco Pivetta [ 30/Jun/14 ]

Handled in pull request https://github.com/doctrine/dbal/pull/625





[DBAL-931] pgSql boolean conversion Created: 30/Jun/14  Updated: 30/Jun/14  Resolved: 30/Jun/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: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: type

Issue Links:
Reference
is referenced by DBAL-863 [GH-564] [DBAL-630] Incorrect Postgre... Resolved
is referenced by DBAL-811 [GH-527] Birko boolean conversion Resolved

 Description   

See DBAL-811 and DBAL-863

PR at https://github.com/doctrine/dbal/pull/625



 Comments   
Comment by Marco Pivetta [ 30/Jun/14 ]

Merged at https://github.com/doctrine/dbal/commit/5eb36c7a643d5e44f0eee4ca39e56088527ce146





[DBAL-807] Index renaming in postgresql does not work when index relates to table inside namespace Created: 08/Feb/14  Updated: 30/Jun/14  Resolved: 30/Jun/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: Artur Eshenbrener Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-821 [GH-532] DBAL-807 [DBAL-807] - Added ... Resolved
is referenced by DBAL-822 [GH-533] [DBAL-807] Respect schema wh... Resolved

 Description   
CREATE SCHEMA test;
CREATE TABLE test.table_name (id INT);
CREATE INDEX idx_1 ON test.table_name (id);

If index would be renamed, generated sql is:

ALTER INDEX idx_1 RENAME TO new_index_name;

But valid sql code should be:

ALTER INDEX test.idx_1 RENAME TO new_index_name;


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

Artur Eshenbrener Can you please provide more details about your use case so that we can reproduce it better. How do you get the wrong SQL?

Comment by Artur Eshenbrener [ 22/Feb/14 ]

I've pushed failing test, reproduces this problem.
https://github.com/doctrine/dbal/pull/532

Comment by Doctrine Bot [ 22/Feb/14 ]

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

Comment by Steve Müller [ 22/Feb/14 ]

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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

Comment by Marco Pivetta [ 30/Jun/14 ]

Resolved in DBAL-822





[DBAL-821] [GH-532] DBAL-807 [DBAL-807] - Added failing test reproduces a problem. Created: 22/Feb/14  Updated: 30/Jun/14  Resolved: 30/Jun/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
relates to DBAL-807 Index renaming in postgresql does not... Resolved
is referenced by DBAL-822 [GH-533] [DBAL-807] Respect schema wh... Resolved

 Description   

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

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

Message:

Added failing test reproduces problem, decribed in ticket http://www.doctrine-project.org/jira/browse/DBAL-807



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

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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

Comment by Marco Pivetta [ 30/Jun/14 ]

Resolved in DBAL-822





[DBAL-822] [GH-533] [DBAL-807] Respect schema when renaming indexes Created: 22/Feb/14  Updated: 30/Jun/14  Resolved: 30/Jun/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
relates to DBAL-807 Index renaming in postgresql does not... Resolved
relates to DBAL-821 [GH-532] DBAL-807 [DBAL-807] - Added ... Resolved

 Description   

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

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

Message:

Statements for renaming indexes have to include the schema name if applicable.



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

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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

Comment by Marco Pivetta [ 30/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/eeda97b6c4df16b8baeedf6c1cdc69494f3941e8





[DBAL-930] [GH-626] Update PostgreSqlPlatform.php Created: 29/Jun/14  Updated: 29/Jun/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 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.






[DBAL-864] Failure to insert FALSE into a bool column Created: 10/Apr/14  Updated: 27/Jun/14  Resolved: 23/Apr/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: Matthieu Napoli Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have experienced this problem with MySQL, I am not sure how it behaves with other platforms. Also, maybe this duplicates http://www.doctrine-project.org/jira/browse/DBAL-630 but since that issue is specifically about PostreSQL I am creating a separate one.

[Doctrine\DBAL\Exception\DriverException]
An exception occurred while executing 'INSERT INTO ACL_Authorization
(role_id, securityIdentity_id, parentAuthorization_id, entity_class, entity_id, cascadable)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'
with params [2, 2, null, "Account\\Domain\\Account", 2, false]:

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'cascadable' at row 1

I think it's related to https://bugs.php.net/bug.php?id=49255 (PDO fails to insert boolean FALSE to MySQL in prepared statement) which casts FALSE into an empty string.



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

Matthieu Napoli this issue could need some additional environment information. Also, isn't there a parameter count mismatch?

Comment by Steve Müller [ 10/Apr/14 ]

Yeah the VALUES clause looks weird concerning number of parameters. Could you maybe also provide information of how you constructed the query? DBAL? ORM? A little code snipüpet would help...

Comment by Matthieu Napoli [ 10/Apr/14 ]

I removed useless values to clear up the message, don't mind the excessive "?" in "VALUES".

Here is the code that trigger this: https://github.com/myclabs/ACL/blob/master/src/Repository/AuthorizationRepository.php#L62

More explicitly, this is: $connection->insert($tableName, $data) with $data being a simple array.

We are talking about DBAL (else I would have opened the issue in the ORM project), probably master (my constraint is master of ORM).

Regarding the environment, this is weird: I can't reproduce it on Ubuntu (PHP 5.5, MySQL version I don't know). The bug appears on OS X, PHP 5.5.5, MySQL 5.6.17 (just upgraded).

Comment by Matthieu Napoli [ 10/Apr/14 ]

I confirm that this is related to FALSE being casted to string, when I cast the boolean to an int it works. Example:

$data = [
    // ...
    'cascadable' => (int) $authorization->isCascadable(),
];
Comment by Matthieu Napoli [ 10/Apr/14 ]

And to be extra-sure I tried casting to boolean, but I still get the error:

$data = [
    // ...
    'cascadable' => (bool) $authorization->isCascadable(),
];
Comment by Marco Pivetta [ 11/Apr/14 ]

Matthieu Napoli is this due to a change in the ORM, an upgrade on your side or are were you implementing something in your codebase? I just wanted to be sure if this may be due to a breakage on your side or something you're experiencing on your code changes.

Comment by Matthieu Napoli [ 11/Apr/14 ]

There is nothing "new" on my side except the code (I mean I didn't "upgrade" anything): this is a new project I started.

Since I use embedded objects, I required doctrine/orm dev-master (or 2.5-BETA3 I don't know but it's roughly the same). Then I used DBAL to do a simple insert:

$data = [
    ...
    'cascadable' => $authorization->isCascadable(),
];

$connection->insert($tableName, $data);

The tests for this "ACL" project are run using SQLite in memory, and they always pass (on every machine).

When I use the project (as a dependency) in another one, with a MySQL backend, it works (i.e. no error) on my Ubuntu machine but not on my OS X machine.

I will be trying to reproduce it in a test today, however I am on Ubuntu right now (work) so maybe I won't see it.

(side note: I have no idea what's the deal between the Ubuntu and OS X machine, both have PHP 5.5 and a latest version of MySQL...)

Comment by Matthieu Napoli [ 11/Apr/14 ]

So as I feared, the test I wrote passed on my Ubuntu machine but fails on my Macbook.

Here is the test: https://github.com/mnapoli/dbal/compare/DBAL-864 As you can see it's as simple as it can be.

Exception : [Doctrine\DBAL\Exception\DriverException] An exception occurred while executing 'INSERT INTO dbal864tbl (foo) VALUES (?)' with params [false]:

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'foo' at row 1

With queries:
3. SQL: 'INSERT INTO dbal864tbl (foo) VALUES (?)' Params: ''
2. SQL: 'CREATE TABLE dbal864tbl (foo TINYINT(1) NOT NULL) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params:

The test passes with SQLite however…

Comment by Matthieu Napoli [ 11/Apr/14 ]

I am confused by the explanation given in https://bugs.php.net/bug.php?id=49255 but I tend to think it's related. When I run the test in debug and step by step, I confirm that the data passed to PDO is array(false). The casting of false to '' happens inside PDO.

Edit: It's starting to make sense, have a look here: https://bugs.php.net/bug.php?id=33876

The PDO documentation says that PDOStatement::execute says that "All values are treated as PDO::PARAM_STR" (http://php.net/manual/en/pdostatement.execute.php), whereas this should work:

$res->bindValue(1, false, PDO_PARAM_BOOL);
$res->execute();
Comment by Steve Müller [ 23/Apr/14 ]

I think this is not a problem with DBAL but rather a usage problem (as stated in the PHP ticket). Please use the third $types argument for $connection->insert() and pass \PDO::PARAM_BOOL there or cast to integer as you did in your example.
The Connection::insert() and related methods don't have enough context to know that the column you are inserting is of type boolean so you have to deal with it manually. This is why PDO has types...

Comment by Matthieu Napoli [ 23/Apr/14 ]

I understand your point, but a boolean is a boolean, DBAL can know what to do with it. It's an "abstraction layer", I would expect it to abstract this problem for me. That's the kind of added value I'm looking for in a DBAL.

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

I get what you mean but what you want is just to magic at that level I suppose. Connection::insert() is at a very low level and mainly just a wrapper around a prepared statement. How would you expect this method to find out the correct DBAL type? Checking each value's PHP type and evaluate the appropriate DBAL type? First off this would add a lot of performance overhead and does not ensure that the correct binding type is used in the end. Imagine that you can also have custom DBAL types with custom binding information and data conversion.
Just do something like this:

$connection->insert('some_table', array('some_column' => false), array('some_column' => 'boolean'));

Basically in the third argument you define the DBAL type name mapping which converts the value appropriately for the underlying platform and chooses the correct PARAM binding type.

In the end there is a reason why PDO doesn't have this kind of magic either and adding a type abstraction layer that is platform independant on top of it makes it even more difficult to do what you would expect.
Hope this helps.

Comment by Matthieu Napoli [ 23/Apr/14 ]

> Hope this helps.

Yes it does, I still have mixed feelings about this but it makes sense (and I didn't think about custom types). Thanks.

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

I share your opinion to some extent. But this task is not as trivial as it seems. Especially when it comes to provide an implementation that behaves the same on all vendors, platforms and versions.
You might want to look at this: http://www.doctrine-project.org/jira/browse/DBAL-630 just to get an idea what a mess this is.

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

Closing this issue for now.

Comment by Doctrine Bot [ 27/Jun/14 ]

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





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

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

Type: Documentation 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 rvdbogerd:

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

Message:

I've moved and changed the comment made by @mikeSimonson to the Abstract ```Statement``` parent class.



 Comments   
Comment by Marco Pivetta [ 27/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/e7a917e9eddd38e9fb37afd6ef95e1b542304a53





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

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved 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





[DBAL-778] [GH-504] Decode hex-encoded clobs/blobs when using pgsql on windows Created: 09/Jan/14  Updated: 26/Jun/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 Seldaek:

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

Message:

http://stackoverflow.com/a/15112973 explains the why. It'd be great to offer support for this natively. I run an `->executeQuery('SET bytea_output=escape')` every time now as a workaround but that's not very nice.






[DBAL-800] [GH-522] Update DB2Platform.php to add ORDER BY data. Created: 30/Jan/14  Updated: 26/Jun/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.






[DBAL-804] [GH-523] SQLSTATE[HY093]: Invalid parameter number: parameter was not defined Created: 06/Feb/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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

OSX 10.8, PHP5.4, MySQL56


Issue Links:
Duplicate
is duplicated by DBAL-803 SQLSTATE[HY093]: Invalid parameter nu... Resolved

 Description   

I am using this code from documentation

QueryBuilder Positional with ?
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME']);
$query->execute();

... and I also tried

QueryBuilder Positional with ?1
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?1')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME']);
$query->execute();

but I got this error:

Error in test case deletePositionalParameter
File: vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php
Line: 91
An exception occurred while executing 'DELETE FROM test_t3lib_dbtest WHERE fieldblub = ?' with params [1391699318]:

SQLSTATE[HY093]: Invalid parameter number: parameter was not defined

When I provide a type to setParamter like

QueryBuilder Positional with ?1 and type
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = ?1')
$query->setParameter(1, (int)$GLOBALS['EXEC_TIME'], \PDO::PARAM_INT);
$query->execute();

or when I changed it to a named query it works

QueryBuilder Positional with named query
$query = $this->subject->getDatabaseHandle()->createQueryBuilder();
$query->delete($this->testTable)->where($this->testFieldSecond . ' = :test')
$query->setParameter(':test', (int)$GLOBALS['EXEC_TIME']);
$query->execute();

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

Message:

Creating Unit Tests to proof the behavior. Its my first PR and I
don't know if I created the Unit Test in the right place. It was the
location where the test actually writing to database which is needed
provoke the error.

DBAL-803 #Provides a test for this issue



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

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

Comment by Benjamin Eberlei [ 08/Feb/14 ]

Fixed in the docs.





[DBAL-808] [GH-525] Added flags support for mysqli::real_connect in Mysqli driver. Created: 08/Feb/14  Updated: 26/Jun/14  Resolved: 26/Jun/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: 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 marcini:

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

Message:

This is necessary if you want to set connection options like compression or SSL encryption.

Recently I wanted to use DBAL with Mysqli driver and I noticed that there is no possibility to enable connection compression, which is done in mysqli by setting flags to mysqli::real_connect. DBAL Mysqli driver lacks support for setting any flag, so I decided to propose my change to add such possibility.



 Comments   
Comment by Marco Pivetta [ 26/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/57186d5c6a02ca23aebc4655b6b89de5fb8808e0





[DBAL-827] [GH-537] Update PDOConnection.php Created: 04/Mar/14  Updated: 26/Jun/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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Remove lot of if making beautifull code using call_user_func_array



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

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





[DBAL-849] [GH-554] Add support string date modifiers for SqlitePlatform Created: 26/Mar/14  Updated: 26/Jun/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: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

In some cases we need support of non-numeric date(datetime) modifiers.
For example if we store interval-value-field in the table. Sqlite doesn't support 'field day' modifier. Common solution for this case is concatenate interval to a string: '' || field || 'day'



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

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





[DBAL-867] Doctrine\DBAL\Driver\Connection should be marked as an internal interface Created: 16/Apr/14  Updated: 26/Jun/14

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

Type: Documentation Priority: Major
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently, the main entry point Doctrine\DBAL\Connection is documented as a wrapper around Doctrine\DBAL\Driver\Connection.
This is very misleading and encourages other library to typehint against Doctrine\DBAL\Driver\Connection rather than Doctrine\DBAL\Connection. See https://github.com/symfony/symfony/pull/10720 for the original discussion.

However, the discussion in https://github.com/doctrine/dbal/pull/414#discussion_r7688765 implies that they should actually not be related together (but it cannot be fixed for BC reasons). The phpdoc should at least be changed



 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

This issue was fixed some time ago.

Commit reference: https://github.com/doctrine/dbal/commit/5fdedc4f8f304e8035580807bd36d59e97a87265

Comment by Steve Müller [ 22/Apr/14 ]

Guilherme Blanco How is your commit reference related to this issue?

Comment by Guilherme Blanco [ 22/Apr/14 ]

Steve Müller The suggestion about Doctrine\DBAL\Connection and Doctrine\DBAL\Driver\Connection started around the misleading support of ping and how to consistently support it across different drivers.
The commit reference I pointed out is Benjamin Eberlei's resolution to remove misleading phpdoc around ping support (which is also highlighted in the ticket as "phpdoc should at least be changed").
If there's anything else that is missing, I'm probably not seeing. All I've done is followed dbal's discussion. =\

Comment by Christophe Coevoet [ 22/Apr/14 ]

Your commit does not fix it at all. Benjamin Eberlei's comment was about the ping method only indeed. But he explained that Doctrine\DBAL\Connection should actually not be a Doctrine\DBAL\Driver\Connection except for legacy reasons, which is why makign it implement Doctrine\DBAL\Driver\PingableConnection was a bad idea even if it has a ping method.

My issue is related to the description of the class itself: https://github.com/doctrine/dbal/blob/aa2ed45ade6582a24e4f72f674f6989873d72112/lib/Doctrine/DBAL/Connection.php#L36
It still describes it as a wrapper around the driver connection, making other devs think that the right typehint in other libraries is the internal driver connection. See the discussion in the Symfony PR I linked

Comment by Guilherme Blanco [ 22/Apr/14 ]

So... it's reopened. I'll look into this later today.

Comment by Marco Pivetta [ 26/Jun/14 ]

Guilherme Blanco can you re-check this?





[DBAL-894] [GH-595] Add testGivenForeignKeyWithZeroLength_acceptForeignKeyThrowsException Created: 05/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/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 JeroenDeDauw:

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

Message:



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/8f2fbf1146ad5152722c175c6238d8e672731892





[DBAL-895] [GH-596] Fix type hint Created: 05/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/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 JeroenDeDauw:

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

Message:



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/321e496350c55b326940ffde86f4c9efb87f8736





[DBAL-896] [GH-597] Some much needed cleanup in the TestUtil class Created: 05/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/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 JeroenDeDauw:

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

Message:



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/aa56a440cc24187ac8d2a14bc3566c3a49a9c588





[DBAL-898] [GH-599] Oracle DateTime sql declaration changed to DATE from TIMESTAMP Created: 07/May/14  Updated: 26/Jun/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 biohazardo:

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

Message:

SQL declaration of DateTime doctrine type is DATE, not TIMESTAMP. Oracle stores date and time in one type DATE.

getDateTypeDeclarationSQL returns DATE, getTimeTypeDeclarationSQL returns DATE types for Oracle. It is justified to return DATE type for getDateTimeTypeDeclarationSQL.



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

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





[DBAL-899] Escape table name when update schema Created: 07/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/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: Guilherme Santos Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: mysql, orm, schematool


 Description   

I have a table called by load and a field called by release, but in MySQL these are reserved names, and should be called inside of ``. In my annotations I use like that:

@ORM\Table(name="`load`") and
@ORM\Column(name="`release`", length=15)

These lines work good when use ORM, but when I use schema-tool the `` are ignored and it's generate something like that:

ALTER TABLE load CHANGE version release VARCHAR(60) DEFAULT NULL;

And to MySQL it's wrong, the right statement is:

ALTER TABLE `load` CHANGE version `release` VARCHAR(60) DEFAULT NULL;



 Comments   
Comment by Marco Pivetta [ 07/May/14 ]

Guilherme Santos can you verify if master (dbal+orm) fixes this? There has been some work on this issue.

Comment by Steve Müller [ 07/May/14 ]

Moved to DBAL, this is unrelated to ORM.

The table quotation issue has been fixed in 2.5/master in commit: https://github.com/doctrine/dbal/commit/75d35f5809095b37cb7085a9289eca4aa9c6df68

The column quotation issue is weird. There has been a fix in 2.5/master in commit: https://github.com/doctrine/dbal/commit/5156391b5686a2b3bba628bb0bc1fece63409a44 for the OLD column name but according to your example the NEW column name is not quoted. But that is working for ages already.

Can you please verify with the latest master as suggested by Marco Pivetta and maybe post the exact generated SQL by the schema tool?

Comment by Guilherme Santos [ 07/May/14 ]

It was fixed, a lot of index was changed too, but the quotation works!
Thanks...





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

Status: Open
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: Benjamin Eberlei
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");
    }





[DBAL-905] [GH-604] Remove some not needed FQNs Created: 13/May/14  Updated: 26/Jun/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 JeroenDeDauw:

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

Message:



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

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





[DBAL-910] QueryBuilder fails when using alias in having with like expr Created: 21/May/14  Updated: 26/Jun/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: Webdevilopers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: GROUP_CONCAT, dql, expression, having, like, mysql
Environment:

Debian, MySQL, PHP, Zend Framework 2, Doctrine Module, Doctrine Extensions



 Description   

In my select I create an alias. I use a like expr on this alias in the having clause.

Trying several variations I still get the following error:
Expected '.' or '(', got 'long_name'

My example including variations inside comments:

$having = $qb->expr()->like('long_name', $qb->expr()->literal('%' . $term . '%'));

$qb->select(array(
    'b.id', 'b.name AS branch_name',
    'c.name AS company_name',
    'GroupConcat(b.name, \', \', c.name) AS long_name' // same for 'c.name AS long_name'
))
->from('Application\Entity\Branch', 'b')
->join('b.company', 'c')
->where('b.compartment = 1')
->having('(' . $having . ')') // same for having($having)
->groupBy('c.id')
->orderBy('c.name')
->addOrderBy('b.name');

I use a Doctrine Extension for the MySQL GROUP_CONCAT functionality:
https://github.com/beberlei/DoctrineExtensions/blob/master/lib/DoctrineExtensions/Query/Mysql/GroupConcat.php

This should have no effect on the result since I tried a simple alias - see comment - instead of it.

The problem seems to be using an alias inside the having clause when adding the like expr.
The following clause would work:

$having = $qb->expr()->like('c.name', $qb->expr()->literal('%' . $term . '%'));

I also tried this workaround using the GROUP_CONCAT method inside the where part:

->andWhere($qb->expr()->like('GroupConcat(b.name, \', \', c.name)', $qb->expr()->literal('%' . $term . '%')))

Allthough I used the groupBy part I got this error:
General error: 1111 Invalid use of group function



 Comments   
Comment by Marco Pivetta [ 26/Jun/14 ]

What is the actual failure/exception type? What about the generated SQL?





[DBAL-914] the pdo_mysql driver do not always trhow an error when mysql does Created: 29/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: mikeSimonson Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: mysql

Attachments: Text File 0001-testcase-for-a-bug-in-the-pdo_mysql-driver.patch    

 Description   

When a query get passed to mysql with the pdo_mysql driver and that the query end with a double semicolon "Create table test (test vachar(1));;". Mysql throw an error and stop the execution of the query there (aka in between the first and the second semicolon).
That problem does not exist with the mysqli driver that correctly throw an error.



 Comments   
Comment by Marco Pivetta [ 29/May/14 ]

Doesn't look like a DBAL bug to me.

As far as I know, PDO does not support multiple queries at all, while mysqli does.

Comment by mikeSimonson [ 30/May/14 ]

I suppose it does because if I insert a sql stmt, in between the two semicolon, it gets executed.

I discovered that bug because I had one statement that created 20 tables or so and that someone edited it manually adding the second semicolon by mistake.
And suddenly all that was after that double semicolon wasn't executed anymore.

To be exact, I'd discover the bug using doctrine migration.
I have made a little patch that you can use to test that case.
For the test to run you will need to adapt the credential found in the Doctrine\DBAL\Migrations\Tests\MigrationTestCase file (after applying my patch).
If you replace in that file pdo_mysql with mysqli the dirver correctly issue an error while the other does not.
I have the impression that the root issue is that when mysql is given a statment with 2 semicolons at the end, it throws an error but with an empty errno.
You can test that directly in mysql console.

Thanks

Comment by Marco Pivetta [ 06/Jun/14 ]

See https://bugs.php.net/bug.php?id=61613

Comment by Marco Pivetta [ 26/Jun/14 ]

Bug depends on a php-src bug





[DBAL-917] [GH-612] Update security.rst Created: 04/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This is more readable (IMO).



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/059df427266d5f75326941dbb83b934696e49ed3





[DBAL-859] OraclePlatform: rownum should not be used directly in WHERE clausule Created: 12/Feb/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Critical
Reporter: Mariusz Jaskółka Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None
Environment:

Oracle, All OSes.


Attachments: File OraclePlatform.php     File OraclePlatform_bugfix.php    

 Description   

At 90% of cases when we use ROWNUM in WHERE clause it will work correctly, but sometimes not. I noticed that that is why Doctrine sometimes works incorrect.
Source:
http://www.oracle.com/technetwork/issue-archive/2006/06-sep/o56asktom-086197.html

Quote:
"That is why a query in the following form is almost certainly an error:

select *
from emp
where ROWNUM <= 5
order by sal desc;
"

I prepared modified OraclePlatform.php with solution (attachment) - rownum is being compared after all operations.



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

Mariusz Jaskółka can you please provide an example where the current implementation fails? We have functional tests LIMIT queries in DBAL but they run fine on Oracle. I need more information to be able to reproduce this problem.

Comment by Marco Pivetta [ 26/Jun/14 ]

This issue is missing a valid test case - marking as incomplete.





[DBAL-866] Foreign Key Constraints does not work with Doctrine/Symfony and SQLite Created: 12/Apr/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Christian Stoller Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 1
Labels: None
Environment:

PHP 5.5.9, SQLite3 module version 0.7-dev, SQLite Library 3.8.3.1



 Description   

I have posted a question on stackoverflow already to get help on this issue, but nobody could give me a sufficient answer. See here.

#370 says that support for foreign keys support for SQLite has been implemented. But in my case it does not work. I have defined two entities:

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Category:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    oneToMany:
        ministries:
            targetEntity: Ministry
            cascade: [persist]
            mappedBy: category

And

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Ministry:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    manyToOne:
        category:
            targetEntity: Category
            inversedBy: ministries
            joinColumn:
                name: category_id
                nullable: false
                onDelete: CASCADE

But when I delete a category, the ministry entities do not get deleted, although the constraint should cascade. What am I missing?

Do I have to configure anything to get that working or is it a bug?



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

While some FK functionalities are supported by the DBAL, I reverted the feature in https://github.com/doctrine/dbal/commit/7282289fee625a24c26c1fccc0474e8ca583470f since it was too clunky, so the ORM doesn't recognize the platform as a platform that supports FKs.





[DBAL-919] [GH-615] Add sanitization for IN() expressions Created: 05/Jun/14  Updated: 26/Jun/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.






[DBAL-794] [GH-517] Fix method signature in Doctrine\DBAL\Driver\Connection Created: 19/Jan/14  Updated: 26/Jun/14  Resolved: 26/Jun/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: Won't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-799 [GH-521] Fix Connection Interface Resolved

 Description   

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

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

Message:

The method ``prepare`` must have an optional driverOptions parameter to be compatible with class which implement the interface Doctrine\DBAL\Driver\Connection.

To avoid this problem:

HipHop Fatal error: Declaration of Doctrine\DBAL\Driver\PDOConnection::prepare() must be compatible with that of Doctrine\DBAL\Driver\Connection::prepare() in /home/travis/build/symfony/symfony/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 30



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

The API was actually fixed by the HHVM folks, so we don't need the PR anymore.





[DBAL-777] [GH-503] Decode hex-encoded clobs/blobs when using pgsql on windows Created: 09/Jan/14  Updated: 26/Jun/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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

http://stackoverflow.com/a/15112973 explains the why. It'd be great to offer support for this natively. I run an `->executeQuery('SET bytea_output=escape')` every time now as a workaround but that's not very nice.



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

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

Comment by Jordi Boggiano [ 09/Jan/14 ]

This was reopened now

Comment by Doctrine Bot [ 26/Jun/14 ]

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

Comment by Marco Pivetta [ 26/Jun/14 ]

The bug is caused by an external library, and we shouldn't attempt to hotfix it.





[DBAL-921] [GH-616] Always store dates in UTC Created: 11/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

Status: Closed
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 LinusU:

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

Message:

This PQ will make sure that the dates saved in the database (without indication of timezone) is always stored in the UTC timezone.

I was doing development on my machine in Sweden when I noticed that when I created a `DateTime`, stored it in the db and then retrieved it again, the time was off by two hours. This is because a created the `DateTime` object with the UTC timezone. Doctrine then saved it straight to the database (by using `$date->format(...)`) and thus the information about which timezone it was in was lost. When doctrine then fetched the value, it used `DateTime::createFromFormat(...)` to create a `DateTime` for me. The problem is that since the timezone wasn't saved anywhere, it assumed that it was a Swedish date, and thus it removed two hours.

I believe that the correct way of doing it is to store the dates in the db as UTC. Then it will always work no matter what the default timezone is, even if I later decide to change it.

`date_default_timezone_set('UTC')` is not the answer. If I use it, I need to make sure that every `DateTime` that I pass to doctrine always has the timezone set to `UTC`. Since the `DateTime` can come from any number of sources (e.g. third party library) it could easily introduce hard to detect bugs. It will also output every date in the UTC timezone which may not be what I want if I'm developing a localised site (e.g. small page for a local Swedish business).



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

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





[DBAL-642] Generated IDs are not guaranteed to be unique over the table's lifetime in SQLite Created: 27/Oct/13  Updated: 25/Jun/14

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

Type: Bug Priority: Major
Reporter: flack Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

In

http://docs.doctrine-project.org/en/2.0.x/reference/basic-mapping.html#identifier-generation-strategies

it says that MySQL and SQLite use AUTO_INCREMENT by default. The generated SQL for creating an ID field with GENERATOR_TYPE_AUTO looks like this (abbreviated
for readability):

CREATE_TABLE_TEST (id INTEGER DEFAULT 0 NOT NULL, PRIMARY KEY(id))

http://www.sqlite.org/faq.html#q1 states:

If you declare a column of a table to be INTEGER PRIMARY KEY, then whenever you insert a NULL into that column of the table, the NULL is automatically converted into an integer which is one greater than the largest value of that column over all other rows in the table, or 1 if the table is empty. [...] Note that the integer key is one greater than the largest key that was in the table just prior to the insert. The new key will be unique over all keys currently in the table, but it might overlap with keys that have been previously deleted from the table.

So in other words, if you remove an entity and then create a new one, the new one will have the same id as the previously deleted one. If you do both operations on the same entitymanager, id references (in proxies f.x.) will suddenly get confused and point to something else (at least that's my current theory..)

The point is: SQLite doesn't act like MySQL as the documentation implies, and IMHO SQLite's current behaviour makes it useless for more complex scenarios. I've found some reference to this problem here:

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

Unfortunately, it doesn't mention any solution. The problem is that you can't override the columnDefinition, because it would have to be "INTEGER PRIMARY KEY AUTOINCREMENT", but then, you get an exception, because the Platform appends ", PRIMARY KEY(id)", so it's defined twice



 Comments   
Comment by Steve Müller [ 25/Nov/13 ]

As far as I understand there is a conflict in SQLite between having an autoincrement primary key and having a composite primary because you can only choose either way. The PR you referenced removed the autoincrement behaviour in favour of having the opportunity to define composite primary keys. So what would you expect to be the solution here?

Comment by flack [ 25/Nov/13 ]

Well, from a user's point of view, it would be nice if the SQLite Platform implementation would make full use of the possibilities of SQLite. That is to say: If someone uses composite primary, they get the behaviour Doctrine has right now, and those that use the simple case (which is recommended all over the documentation), get the behaviour previous to the pull request, i.e. autoincrement that works like in MySQL (which the documentation implies). As far as I understood the discussion in the pull request, the author was looking for a solution to implement this, but then the PR was merged before the issue was solved.

Comment by flack [ 25/Nov/13 ]

I guess what is bothering me is that the current behaviour breaks assumptions that I think many applications using Doctrine make. At least I know that in my own code, I never planned for the possibility of a database primary key being re-used for a different object, especially not during the same request. And like I wrote above, I suspect that Doctrine itself is not totally prepared for that situation either (also mentioned here: https://github.com/doctrine/dbal/pull/66#discussion_r173623). So IMHO the IDENTIY generator strategy for SQLite seems broken, or at least is behaving unexpectedly. The documentation says

AUTO (default): Tells Doctrine to pick the strategy that is preferred by the used database platform. The preferred strategies are IDENTITY for MySQL, SQLite and MsSQL and SEQUENCE for Oracle and PostgreSQL. This strategy provides full portability.

I don't really see how the current behaviour can be said to provide full portability (at least with MySQL, which supposedly uses the same preferred strategy)

Comment by Steve Müller [ 25/Nov/13 ]

Yeah I get your point. But it's always hard and error prone to work around the vendors lack of common features. A possibility COULD be to implement a trigger in columns declared as autoincrement which simulates the behaviour of an auotincrement column on inserts. Oracle uses a similar workaround with a trigger and a sequence to simulate autoincrement columns. But this is just an idea and has to evaluated for usability first.

Comment by Steve Müller [ 25/Nov/13 ]

Yes that's true. The documentation is misleading here. I guess that it was written before the issue came up and then was not updated. Unfortunately SQLite does not support native sequences which would make life a lot easier. But I will keep that in mind and investigate a solution for this.

Comment by Benjamin Eberlei [ 13/Dec/13 ]

I think there is no fix for this, this is just how SQLite works, and we cannot really keep the last ids somewhere. IMHO its a documentation issue.

Comment by flack [ 13/Dec/13 ]

Well, you cannot fix it for cases with multiple id columns (but the Doctrine documentation already suggests that they should be avoided where possible), but for single integer columns (which is the normal case, as suggested by documentation), SQLite provides all the necessary functionality, as long as you create the column with INTEGER PRIMARY KEY AUTOINCREMENT. So IMHO the best solution would be if support for this could be implemented somehow in the SQL Platform driver.

Comment by flack [ 14/Dec/13 ]

Case in point: I implemented exactly this in a Doctrine adapter I'm working on:

https://github.com/flack/midgard-portable/blob/master/src/midgard/portable/storage/subscriber.php#L136

Granted, this is a very ugly workaround that only works because I know all my ID columns are actually called 'id' (and will never change), but I'm fairly sure that a more general solution could be built with reasonable effort.

Comment by Benjamin Eberlei [ 01/Jan/14 ]

flack We removed the Sqlite AUTOINCREMENT for some weird reason. I am inclined to add this again, however I need to find out what the reasons for removing this have been.

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

Benjamin Eberlei I checked that lately and I came to the same conclusion. The reason why it was removed is to support composite primary keys which was not possible before somehow. We could add autoincrement if only a single column integer primary key is given I think...

Comment by flack [ 25/Jun/14 ]

Just noticed that the link I posted above is broken now. Here's a stable one:

https://github.com/flack/midgard-portable/blob/04d473356d804c7f64e940ef82dd1538c39fccdd/src/storage/subscriber.php#L170

The workaround is a bit less project-specific now, and might serve as the basis for a real solution I guess (basically, only checks for column type and composite keys would need to be added)





[DBAL-928] [GH-623] Prevent Connection from maintaining a second reference to an injected PDO object. Created: 25/Jun/14  Updated: 25/Jun/14  Resolved: 25/Jun/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 jgallred:

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

Message:

Previously, if a developer explicitly closed the Connection, only the _conn reference was destroyed, but the _params['pdo'] reference remained and kept the PDO connection alive. By unsetting the _params reference, we maintain only the _conn reference, exactly as if the PDO connection is generated internally.



 Comments   
Comment by Marco Pivetta [ 25/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/cf35f1930edc00b264b06f04d9e1f616cc440581





[DBAL-926] [GH-621] Use PSR-4 for Doctrine DBAL Created: 20/Jun/14  Updated: 20/Jun/14  Resolved: 20/Jun/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix 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/621

Message:

symfony/symfony#11189 for Doctrine DBAL



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

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





[DBAL-925] [GH-620] Correct SQL Anywhere driver default port to 2638 Created: 19/Jun/14  Updated: 19/Jun/14  Resolved: 19/Jun/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

It looks like this was a simple typo.

References:
SQLA16 - http://dcx.sybase.com/index.html#sa160/en/dbadmin/serverport-network-conparm.html
SQLA12 - http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.11.0.1/dbadmin_en11/serverport-network-conparm.html

It probably wasn't noticed immediately due to the fact SQL Anywhere drivers cache database server address information in a file on disk (sasrv.ini). Once the cache is populated with the database name, it's possible to connect successfully even if the port you were specifying in your code was incorrect (like 2683).

http://dcx.sybase.com/1201/en/dbadmin/servernamecaching.html



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

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

Comment by Marco Pivetta [ 19/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/247bd099b8f74eed3d7bdb42a5e0bb1af1925dce





[DBAL-922] [GH-617] deleted invalid target for quantifier Created: 11/Jun/14  Updated: 11/Jun/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.






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

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

Type: Improvement Priority: Minor
Reporter: Matteo Beccati Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
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-915] emulate named parameters for statement with the mysqli driver Created: 30/May/14  Updated: 05/Jun/14  Resolved: 03/Jun/14

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

Type: Improvement Priority: Major
Reporter: mikeSimonson Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-918 [GH-614] Correcting the doc because m... Open

 Description   

Hi,

Would it be reasonable to try to emulate named parameters in the mysqli driver?

The goal is that we still could use named parameters and that the DBAL mysqli driver would automatically replace the named parameters by questions marks and pass the parameters in the right order according to those question marks ?

The main problem I see is that we might replace stuff in the query that shouldn't be replaced. And in that case it might be good to have a way to disable that behavior (don't know if it's easy to do in the DBAL code base).
On the other hand we could also ask the user to change it's parameter name even if it's not ideal it's also probably the fastest fix. The corner problem here is that I don't know the rules that are applied by pdo_mysql to replace the named parameters in a prepared statement, if there are any.

Is it a good or bad idea and why ?
Thanks



 Comments   
Comment by mikeSimonson [ 31/May/14 ]

Btw I just realised that in the mysqli doctrine driver documentation it's indicated as supported. So maybe I should just add it.

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

mikeSimonson I'm not quite sure what your issue is here as the DBAL Connection already converts named parameters into positional parameters under the hood. See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php
Or am I getting you wrong here?

Comment by mikeSimonson [ 02/Jun/14 ]

Is it possible that I did something the wrong way so that, that emulation is not used.
My query is only a select with " WHERE id = :id ". That crash telling me that there is an error in my sql syntax and when I replace it with " WHERE id = ? " it works perfectly.
That is with the mysqli driver on symfony2.4.

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

Can you provide a code snippet of how you executed the query? Did you use the DBAL\Connection object? AFAIK you cannot use the mysqli driver connection directly because the parameter conversion from named to positional is done through DBAL\Connection

Comment by mikeSimonson [ 02/Jun/14 ]

I am in a Repository (entity) and I am using

 $this->getEntityManager()
            ->getConnection()
            ->prepare("SELECT * FROM person WHERE id =:id");

/** The query is trimmed for readability **/

Comment by mikeSimonson [ 02/Jun/14 ]

Just to make sure I tested with that exact same query.

If I use pdo_mysql the query runs fines and then I change the driver in the dbal config file to mysqli and it tell me that my sql is wrong. I change the sql to use question mark and it's fine again.

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

DBAL\Connection::prepare() does not convert named into positional parameters. It works with pdo_mysql because pdo_mysql supports named parameters natively. You have to use one of the other (direct) query methods like DBAL\Connection::fetch*() or DBAL\Connection::executeQuery().

Comment by mikeSimonson [ 02/Jun/14 ]

So, what you say is that it's not possible to have prepared statement with named parameter and mysqli.
And I want to hook that sqlParserUtils method to be able to use the named parameters with mysqli statement too.

Does that make sense ?

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

Sure you can have a prepared statement and named parameters with mysqli. It's just that DBAL\Connection::prepare() gives you a "raw" prepared statement, whereas executeQuery() gives you a prepared statement with a preprocessed SQL (named to positional conversion, array parameter expansion etc.). I think the fact that DBAL\Connection::prepare() does not convert the parameters for you automatically is that it does not take any parameters (as you have to bind them manually afterwards) which is necessary for the SQLParserUtils to rewrite the SQL appropriately. So either use one of the fetch*() methods with named parameters to retrieve a result directly or use exceuteQuery() to get a prepared statement (with converted named parameters). If you however really want to use prepare() (for whatever reason) then you will have to utilize the SQLParserUtils manually in order to get your named parameters converted into positionals before executing the query.
Hope this helps.

Comment by mikeSimonson [ 02/Jun/14 ]

Ok.

So it's just a misunderstanding of my part that to have a prepared statement you need to use the prepare method.
In that case I will just use the executeQuery or query.

Thanks for you help.

What are the differences then between all those methods then.
Also when I look in the documentation it quite unclear I think.
If you go in the mysqli driver documentation it states that the driver support the prepared statement with a named parameter.
At least it's that way that I understand it.

When I will have understand the difference between all those method I will try to explicit it in the documentation.

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

Please have a look at the DBAL documentation to understand the differences between the available query methods in Doctrine\DBAL\Connection:

http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/data-retrieval-and-manipulation.html#api

The reason why the mysqli driver API documentation states, it supports also named parameters is because the documentation is inherited from the Doctrine\DBAL\Driver\Statement interface which Doctrine\DBAL\Driver\Mysqli\MysqliStatement implements. Basically the interface is adopted from PHP's \PDOStatement and therefore a bit misleading here concerning named parameters, that's true. Sorry for the confusion.

Comment by mikeSimonson [ 03/Jun/14 ]

TLDR;
It seems that executeQuery fails to treat the param as int when it's told too and that a named parameter is used.

Closer look.

I did change the prepare call into a call to executeQuery.
It now looks like that:

$stmt = $this->getEntityManager()
            ->getConnection()
            ->executeQuery("
                      SELECT ..... FROM ..... lots of join 
                      WHERE id = :id
                     ", array('id' => 10000107),
               array(\PDO::PARAM_INT)
);

That query fails miserably (aka mysql use 100% of the processor for what seems like forever and I kill it).
I realized that the query passed to phpmyadmin runs smootly if I write the were like this

                WHERE id = 10000107

but fails also if the query is passed with the id quoted

                WHERE id = '10000107'
                WHERE id = "10000107"

I think that a part of the problem is that when I do executeQuery with a named parameter and a paramType as \PDO::PARAM_INT, the parameter is not passed as an int but as a string.
The funny one is that you can use any quoting you want in your param if you don't use named parameters, and all those run smoothly :

$stmt = $this->getEntityManager()
            ->getConnection()
            ->executeQuery("
                      SELECT ..... FROM ..... lots of join 
                      WHERE id = ?
                     ", array('1' => 10000107),
               array(\PDO::PARAM_INT)
);
, array('1' => '10000107'),
               array(\PDO::PARAM_INT)
);
, array('1' => "10000107"),
               array(\PDO::PARAM_INT)
);

If anyone see any reason why that fails I am more than interested.
Besides the fact that mysql probably shouldn't have any problem with the way the is passed ( as string or int), I also think that executeQuery fails to treat the param as int when it's told too and that a named parameter is used.

What do you think ?

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

Not sure if that fixes the issue but you have to pass a map of types as third argument like

$query = 'SELECT foo FROM bar WHERE id = :id';
$stmt = $this->getEntityManager()
    ->getConnection()
    ->executeQuery($query, array('id' => 10000107), array('id' => \PDO::PARAM_INT));

Otherwise the parameters will be bound without a specific type, therefore seemingly mapping to string by default.
See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Connection.php#L1477-L1483

Edit: Sorry fixed the example.

Comment by mikeSimonson [ 03/Jun/14 ]

Aarg just saw your email.

Thanks it works perfectly now.

Comment by mikeSimonson [ 03/Jun/14 ]

Should I just add a new example in the documentation with a named parameter (bellow the one with a positional param) in http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/data-retrieval-and-manipulation.html#executequery ?

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

Yeah might be a good idea to add the corresesponding examples with named parameters for executeQuery(), fetchAll(), fetchArray(), fetchColumn(), fetchAssoc(). Go ahead, open a PR and I'll merge then. Thanks.





[DBAL-332] Memory option for Sqlite driver does nothing Created: 29/Aug/12  Updated: 04/Jun/14  Resolved: 17/Sep/12

Status: Closed
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2, 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Damien ALEXANDRE Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

PHP Version 5.3.10
SQLite Library 3.7.9
Doctrine 2.3.x-dev
Dbal 2.3.x-dev
Symfony 2.1 RC2



 Description   

I'm trying to configure a "memory" sqlite database, as described here: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#pdo-sqlite

So here is my configuration (config_test.yml) :

Unable to find source-code formatter for language: yml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
 
doctrine:
    dbal:
        driver:    pdo_sqlite
        memory:    true
        user:      db_user
        password:  db_pwd
        charset:   UTF8

I'm then running

./app/console doctrine:database:create --env=test

and the result is a "myBdName" db file (the filename contains the quote!!) in my root folder.

I don't understand why the file http://www.doctrine-project.org/api/dbal/2.3/source-class-Doctrine.DBAL.Schema.SqliteSchemaManager.html#46 is creating a path option with my DB name, if I comment the line 57, everything seems fine (no more file created).

I have seen some memory related options in the Doctrine test suite so maybe I'm doing it wrong, and in that case that's a documentation issue I can work on.

Thx,
Damien



 Comments   
Comment by Benjamin Eberlei [ 05/Sep/12 ]

You cannot create an in memory database using Symfonys database:create. The in memory database will be closed when the request ends. So its completly useless this way. You have to recreate it in every request that you want to use it. It is just good for one request.

Comment by Damien ALEXANDRE [ 06/Sep/12 ]

My example with "app/console" is misleading,
what I want to do is building a memory SQLite database on the fly and run some code right after it (in a phpunit test).

The issue here is that there is an option documented (first link) that doesn't work / is not implemented (second link). And a physic file is generated, it should not.

As your answer seems to be based on the mistaken impression that I wanted to use volatile database in a persistent way, I'm reopening this issue.

Thanks for your time.
Damien.

Comment by Benjamin Eberlei [ 07/Sep/12 ]

Try removing the user/password keys. memory database connection works for me, this seems to be a configuration issue.

If you want to create an in memory db for testing then you have to create the schema with SchemaTool inside the phpunit tests.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

No feedback on potential fix, this issue is either misconfiguration or wrong use of the API. I couldn't reproduce this and it works for me (TM).

Comment by Iain Potter [ 04/Jun/14 ]

Hi guys, this does not work for me either. Same use case.

Config:

driver: pdo_sqlite
memory: true

Comment by Iain Potter [ 04/Jun/14 ]

Apologies for resurrecting an old issue but a google search brought me here.





[DBAL-916] Some alter table statements do not respect @Table name value Created: 30/May/14  Updated: 04/Jun/14

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

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

MacOS



 Description   

I have specified the table name for each class generating a table. I find that some table names are respected during doctrine update upon the database, and some are not.

Specifically it seems that simpler entities, one's annotated with entity/table become lower case, while more complicated ones (inheritance map) respect the given table name.



 Comments   
Comment by Julia Smith [ 03/Jun/14 ]

On further inspection, this does not appear to be a bug with Doctrine. A simple dump of the update statements generated shows no table name change, but:

ALTER TABLE Comment DROP FOREIGN KEY FK_5BC96BF03DBEAF48;
DROP INDEX IDX_5BC96BF03DBEAF48 ON Comment;
ALTER TABLE Comment CHANGE replyto_id replytox_id INT DEFAULT NULL;
ALTER TABLE Comment ADD CONSTRAINT FK_5BC96BF0484A4D29 FOREIGN KEY (replytox_id) REFERENCES Comment (id);
CREATE INDEX IDX_5BC96BF0484A4D29 ON Comment (replytox_id);

Somehow causes mysql to change the case of the table on MacOS.

weird.

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

Julia Smith can you please provide more details concerning your actual problem? I'm not sure I understand what the problem is here. I can't see how the SQL you pointed out changes a table's name in any way so I don't understand how that could change the table name's case.
Concerning identifier casing in general I would suggest you to read the following from the MySQL documentation:
http://dev.mysql.com/doc/refman/5.5/en/identifier-case-sensitivity.html

And a pretty good explanation of the problem with identifiers and case accross operating systems and database vendors:
http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html#.U47DV3IZWlM

If the casing of identifiers (table names, column names etc.) in your schema is important for you, you will either have to quote those in your mapping explicitly or use a custom quoting strategy. Please refer to the documentation for further details:
http://docs.doctrine-project.org/en/latest/reference/basic-mapping.html#quoting-reserved-words

Hope that helps.





[DBAL-911] Property access not yet allowed in path/to/MysqliConnection.php Created: 21/May/14  Updated: 22/May/14  Resolved: 22/May/14

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

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


 Description   

Updated doctrine/dbal from 0a7df7c58aeab4d1cef55a78e5ca50299a12a62b to 2.5.0-beta3 and received the following warning:

PHP Warning:  Doctrine\DBAL\Driver\Mysqli\MysqliConnection::__construct(): Property access is not allowed yet in /path/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/MysqliConnection.php on line 60


 Comments   
Comment by Till [ 22/May/14 ]

This duplicates DBAL-912 and can be closed.





[DBAL-912] [GH-611] Fix: property access is not allowed yet Created: 21/May/14  Updated: 21/May/14  Resolved: 21/May/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fixes the warning emitted by mysqli when sqlstate is not set (yet?).
http://git.php.net/?p=php-src.git;a=blob;f=ext/mysqli/mysqli_prop.c;h=2d36336372b75922bd8fbf40c5c9054a5230c8a0;hb=HEAD#l36

Warning masks actual connection error.

Related:
http://www.doctrine-project.org/jira/browse/DBAL-911



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

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

Comment by Benjamin Eberlei [ 21/May/14 ]

Merged





[DBAL-524] [GH-322] DBAL-522 Created: 20/May/13  Updated: 21/May/14  Resolved: 21/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.4
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 Ocramius:

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

Message:

Hotfix for DBAL-522(http://www.doctrine-project.org/jira/browse/DBAL-522)

Demonstrates that NULL parameters are handled incorrectly by `Doctrine\DBAL\SqlParserUtils` as of 2.3.4.

Basically, following usage always throws an exception:

$conn->executeQuery(
    'INSERT INTO FOO (foo, bar) values (:foo, :bar)', 
    array('foo' => 1, 'bar' => null)
);


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

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

Comment by Doctrine Bot [ 21/May/14 ]

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





[DBAL-515] [GH-315] Shard description requires an 'id' not 'name' Created: 14/May/13  Updated: 19/May/14  Resolved: 14/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
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 johannes:

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

Message:



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

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

Comment by Marco Pivetta [ 14/May/13 ]

merged

Comment by Doctrine Bot [ 19/May/14 ]

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





[DBAL-514] [GH-314] Remove unnecessary code from Connection::insert Created: 13/May/13  Updated: 19/May/14  Resolved: 14/May/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
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/314

Message:

This is a tiny optimization in the <code>Connection::insert</code> method that remove an unnecessary <code>foreach</code> loop an some unneeded variable assignments.
If this is not desired, just close this PR



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

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

Comment by Marco Pivetta [ 14/May/13 ]

merged

Comment by Doctrine Bot [ 19/May/14 ]

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





[DBAL-501] [GH-309] Parameter parsing fixes Created: 21/Apr/13  Updated: 19/May/14  Resolved: 09/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.4
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 lstrojny:

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

Message:

Fix for #301 has been reverted to address http://www.doctrine-project.org/jira/browse/DBAL-496. This fix addresses both issues in a consistent manner and ads a few more tests.



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

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

Comment by Doctrine Bot [ 19/May/14 ]

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





[DBAL-840] [GH-546] [DBAL-474] Fix filtering sequence names on PostgreSQL Created: 19/Mar/14  Updated: 16/May/14  Resolved: 16/May/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 deeky666:

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

Message:

The PostgreSQL schema manager has to filter sequence names before actually creating `Sequence` objects to avoid errors on accessing sequence database objects where the user has not enough privileges for.
The reason for this is that retrieving sequence attributes other than the sequence name requires accessing the particular sequence database object directly which requires the connected user to have enough privileges. This might not always be the case if for example a particular user can only access certain schemas but not others.
This patch might not be the best solution but a good compromise IMO. Changing the `AbstractSchemaManager` to filter sequence names before creating `Sequence` objects might affect other platforms and could also perhaps break BC. Furthermore this issue is completely PostgreSQL specific as it is the only currently supported platform not having a sequence's attributes stored directly in the system catalogs (AFAIK).



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

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

Comment by Marco Pivetta [ 16/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/6252da0cf1ed04cc790af533f0841bf5c01de44e





[DBAL-474] SchemaManager / Connection on PostgreSQL platform does not respect filterExpression for sequences Created: 27/Mar/13  Updated: 16/May/14

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

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: postgresql, schematool
Environment:

Windows & Linux



 Description   

Dear Symfony team,

the filterExpression on AbstractSchemaManager seems not to work for sequences.

This only happens under postgres.

It seems the way the sequences are handled are the culprit: It tries to get min_value etc of sequences without matching sequence names to the filter expression in advance.

If for example access to the sequences is denied, (Different schema without permissions for the current entity manager), any higher-level ORM operations like generating migration versions fail.

--------------------- UPDATE

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.



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

Can you paste an exception trace? I see that filtering is applied to sequences, but your description seems to indicate this happens due to an SQL query much earlier?

Comment by jos de witte [ 24/Apr/13 ]

Dear Benjamin,

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.

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

jos de witte I think your issue got fixed in commit: https://github.com/doctrine/dbal/commit/8beb732fe9d5cd40a0d677f250d2be325482744f
This patch was first introduced in 2.3. Can you please confirm that this is fixed? Otherwise can you please provide a concrete example so that we can reproduce you issue?

Comment by Arnout Standaert [ 29/Jan/14 ]

I believe we are bumping into the same issue. Our webapp uses Migrations, but for our webapp we are limited to a certain schema within a bigger PostgreSQL database. We only have permissions on our own schema and public.
Now, listSequences in AbstractSchemaManager does filter the asset names correctly with the mentioned fix.

But the problem is with the step before, _getPortableSequencesList (see line 135 of AbstractSchemaManager):

        return $this->filterAssetNames($this->_getPortableSequencesList($sequences));

This function goes out and does a _getPortableSequenceDefinition on every sequence in the unfiltered list. For every sequence, the _getPortableSequenceDefinition in PostgreSqlSchemaManager performs a SELECT:

        $data = $this->_conn->fetchAll('SELECT min_value, increment_by FROM ' . $this->_platform->quoteIdentifier($sequenceName));

Now, our user role in the database doesn't have SELECT permissions on these sequences in other schemas, so the migration fails with a privilege error.

There should be some kind of filtering on the sequence list BEFORE the SELECT statement in the _getPortableSequenceDefinition function are performed, no?

Comment by Arnout Standaert [ 30/Jan/14 ]

I currently have a workaround running locally, which filters the sequences list before creating the PortableSequence's. This is probably hackish and a poor workaround, just posting here as a temporary solution and further illustration of the problem.

Altered line 135 in AbstractSchemaManager:

        return $this->_getPortableSequencesList($this->filterSequenceNames($sequences));

I added function filterSequenceNames() in AbstractSchemaManager for appropriate sequence filtering:

    /**
     * Filters sequence names if they are configured to return only a subset of all
     * the found elements.
     *5
     * @param array $sequenceNames
     *
     * @return array
     */
    protected function filterSequenceNames($sequenceNames)
    {
        $filterExpr = $this->getFilterSchemaAssetsExpression();
        if ( ! $filterExpr) {
            return $sequenceNames;
        }
        
        return array_values ( array_filter($sequences, function ($sequenceName) use ($filterExpr) {
                $sequenceName = $sequenceName["schemaname"].".".$sequenceName["relname"];
                return preg_match($filterExpr, $sequenceName);
            })
        );

    }

After these modifications, doctrine:migrations:migrate operations complete succesfully, even with our limited-permission database account.

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

Arnout Standaert Your fix looks promising and reasonable. Can you create a PR on the DBAL repo for that?

Comment by Viktor Sidochenko [ 15/Mar/14 ]

Why this fix is not in master?

Comment by Steve Müller [ 15/Mar/14 ]

Viktor Sidochenko because nobody has fixed it yet Feel free to provide a patch on GitHub.

Comment by Arnout Standaert [ 17/Mar/14 ]

I haven't gotten around to doing the PR on GitHub yet, I'm not yet too familiar with that.
I'll try to find some time for this the coming days.

Comment by Viktor Sidochenko [ 17/Mar/14 ]

Will be good. I`m not professional developer to make patches to upstream. So just voted for this issue.

Comment by Steve Müller [ 19/Mar/14 ]

Patch supplied in PR: https://github.com/doctrine/dbal/pull/546
jos de witte, Arnout Standaert, Viktor Sidochenko can you please test if the supplied PR fixes the problem?

Comment by Doctrine Bot [ 16/May/14 ]

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





[DBAL-855] [GH-560] Fix DateTimeTz type compatibility on SQL Anywhere versions < 12 Created: 31/Mar/14  Updated: 16/May/14  Resolved: 16/May/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 deeky666:

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

Message:

SQL Anywhere versions < 12 do not support a native date time with timezone type. Therefore the fallback strategy is to use the normal date time type. However the format of the date time tz type declaration has to correspond to the normal date time type declaration, too then.

`getDateTimeTzTypeDeclarationSQL()` -> `getDateTimeTypeDeclarationSQL()`
`getDateTimeTzFormatString()` -> `getDateTimeFormatString()`

I thought about changing that in the `AbstractPlatform` but I am not sure if that might break assumptions in userland code and therefore BC. So I left the implementation SQL Anywhere specific.



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

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

Comment by Marco Pivetta [ 16/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/ea5ac9588c95c117590de185434ae4adc9020388





[DBAL-856] [GH-561] Fix FOR UPDATE SQL on SQL Anywhere Created: 31/Mar/14  Updated: 16/May/14  Resolved: 16/May/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 deeky666:

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

Message:

It looks like there was a misunderstanding on SQL Anywhere with the `FOR UPDATE` SQL as this is actually a statement used in prepared statements and does not work the ANSI way in ORM. So I removed it in favour of the table lock hint implementation which works out quite well and makes the `getForUpdateSQL()` rather useless anyways. SQL Server does it like this, too btw and both dialects are pretty similar because SQL Anywhere once drived from it.



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

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

Comment by Marco Pivetta [ 16/May/14 ]

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





[DBAL-877] [GH-575] [DBAL-801] Add date arithmetic interval methods for seconds, minutes, weeks, quarters and years Created: 24/Apr/14  Updated: 16/May/14  Resolved: 16/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: 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 deeky666:

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

Message:

This PR adds missing methods for additional date arithmetic interval expression of seconds, minutes, weeks, quarters and years.
Additionally all platforms have been refactored to avoid a lot of code duplication through a more common protected extension point method `AbstractPlatform::getDateArithmeticIntervalExpression()`.



 Comments   
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 Marco Pivetta [ 16/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/d12eb786f3148e099e9cd14c76fba6c179a24629





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

Status: In Progress
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: gondo Assignee: Steve Müller
Resolution: Unresolved 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





[DBAL-44] nullable is not working for all datatypes Created: 30/Aug/10  Updated: 16/May/14  Resolved: 30/Aug/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0-BETA3

Type: Bug Priority: Critical
Reporter: Daniel Freudenberger Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None

Attachments: Text File nullable.patch    
Issue Links:
Reference
is referenced by DDC-1045 Schema-tool update missbehavior: Not ... Closed

 Description  &n