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

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

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

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

 Description   

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

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

This effectively prevents re-creating the database.

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

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

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

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



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

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

Comment by Christophe Coevoet [ 14/Oct/14 ]

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

Comment by Marco Pivetta [ 14/Oct/14 ]

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

Comment by Marcus Malka [ 14/Oct/14 ]

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

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

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

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

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

Comment by Marcus Malka [ 15/Oct/14 ]

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

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

Comment by Benjamin Eberlei [ 26/Oct/14 ]

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

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





[DBAL-844] [GH-549] Fix truncate on MySQL >= 5.5 Created: 22/Mar/14  Updated: 22/Mar/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 ddeboer:

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

Message:

When truncating tables on MySQL >= 5.5, an error is thrown:

```mysql
SQLSTATE[42000]: Syntax error or access violation:
1701 Cannot truncate a table referenced in a foreign key constraint ...
```

It turns out that with MySQL 5.5.7, `TRUNCATE` behaviour has changed. From the [MySQL docs](http://dev.mysql.com/doc/refman/5.5/en/truncate-table.html):

> TRUNCATE TABLE fails for an InnoDB table if there are any FOREIGN KEY constraints from other tables that reference the table. Foreign key constraints between columns of the same table are permitted.

With this PR foreign key checks are disabled just before and re-enabled just after truncate.

As I encountered this issue using doctrine/data-fixtures, I originally submitted a fix there: https://github.com/doctrine/data-fixtures/pull/127. However, as @deeky666 pointed out, the DBAL is a better place for the fix.






[DBAL-846] [GH-551] Foreign key checks on MySQL >= 5.5.7 for TRUNCATE Created: 24/Mar/14  Updated: 24/Mar/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 tPl0ch:

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

Message:

  • Added `ConfigurablePlatform` interface to set the connection
    parameters to the Platform
  • Connection is now setting the parameters to the Platform if it
    implements `ConfigurablePlatform`
  • `MySQLPlatform::getTruncateSql()` now checks for a new param
    `disable_fk_checks`, if it is true and the version is affected, it
    automatically adds the required SQL.

Additional solution to https://github.com/doctrine/dbal/pull/549






[DBAL-798] [GH-520] [WIP] Add pdo informix driver support Created: 28/Jan/14  Updated: 28/Jan/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 josemalonsom:

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

Message:

I have created this branch to add support to PDO_INFORMIX in DBAL.

First I had put a new topic in the doctrine-dev group (https://groups.google.com/forum/#!topic/doctrine-dev/gndS00nxSQA) where i explain some issues i have.






[DBAL-746] [GH-479] [DBAL-624] Fix parsing parameters in comments Created: 29/Dec/13  Updated: 29/Dec/13

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

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


 Description   

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

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

Message:

Parameter placeholders should not be parsed out of comments in statements.






[DBAL-730] [GH-464] [DBAL-139] [WIP] Finish CACHE option implementation for sequences Created: 23/Dec/13  Updated: 23/Dec/13

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

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


 Description   

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

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

Message:

@beberlei Started implementation for DBAL-139(http://www.doctrine-project.org/jira/browse/DBAL-139) in commit https://github.com/doctrine/dbal/commit/e8efcd7621e85003f3ce496bc26a108b53371838 and https://github.com/doctrine/dbal/commit/d397c005dd3ff3d48a81eeb47c2a0d74d6b7400d which was first drafted in PR #202. It's about adding a cache option for sequences.

*The following missing aspects of the implementation were added:*

  • SQL Server support
  • SQL Anywhere support
  • Reverse engineering the cache option with the schema managers
  • Comparator implementation
  • Schema::createSequence() adjustment
  • More tests

*Additional optimizations:*

  • Rename `$cache` to `$cacheSize` in Sequence (unified naming with `$allocationSize`)
  • More strict input validation for cache size values in Sequence to avoid SQL generation errors
  • Better API documentation
  • Unified `getSequenceCacheClause()` method on all platforms

*Todo:*

  • Fix comparator issues (see below)
  • Finish test suite for this (depends on comparator issues solution)

*Comparator issues*
The comparator will get into trouble when comparing cache size values. To get an understanding of this I'll first explain how cache size values evaluate to the database:

  • `null` -> No cache size specified, don't generate cache clause for sequences and use platform's default
  • `0` -> Explicitly disable caching for sequences, generates `NOCACHE` clause on platforms
  • every other positive value is an explicite specification of the cache size and results in `CACHE <size>` clause

Now there are two problems.

First one is that a value of `1` has a special meaning on some platforms, too. Oracle does not accept it and throws an error as the minimum allowed value is `2`. PostgreSQL allows a value of `1` but in fact interprets it as `NOCACHE`. SQL Server and SQL Anywhere accept a value of `1` but the behaviour is unclear compared to an explicite `NOCACHE` on these platforms. Now I am assuming that a cache size of `1` maybe also physically has the same effect as if specifying no cache at all and that this is more of a "compatibility" value and we maybe should not allow it at all to preserve portability throughout the vendors.

The second problem is the `null` value for `$cacheSize` in Sequences. This tells the vendor to use it's own specific default cache size which differs on all platforms. The comparator will always mark a sequence as changed then when `null` was initially defined for the sequence and the sequence is introspected from database again. This will lead to repeated `ALTER SEQUENCE` statements in the schema tool which is not good. Also we cannot determine in the platform itself if the sequence has really changed as there currently is no `SequenceDiff` class which could get passed to `AbstractPlatform::getAlterSequenceSQL()`. Instead we only get the changed sequence object. I have put together some [examples](https://gist.github.com/deeky666/6c4e47a275b1c9e7c068) to clarify on what I mean as it is hard to explain.

So I'm asking for opinions and input on this






[DBAL-715] Using caching with fetchColumn() of single row does not work Created: 20/Dec/13  Updated: 20/Dec/13

Status: Open
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: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-468 [GH-288] Fix fetchColumn not caching Resolved

 Description   

The caching mechanism only triggers when the cursor is fully iterated and the result is closed. This breaks caching for code of the kind:

$cnt = $conn->executeQuery($sql)->fetchColumn();





[DBAL-624] Parameter in comments is parsed Created: 03/Oct/13  Updated: 22/Nov/13

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

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

Issue Links:
Reference
relates to DBAL-552 Colon (":") in field name treats like... Resolved

 Description   

Text in comment is parsed as params.
I.e.:
select abc – :par
from table

select abc /* :par */
from table



 Comments   
Comment by Steve Müller [ 21/Nov/13 ]

Which platform / driver do you refer to? Maybe a duplicate of this?
http://www.doctrine-project.org/jira/browse/DBAL-124

Comment by Vitaliy [ 22/Nov/13 ]

No platform / driver depend. I try test class SQLParserUtils in separate module. And this sql parsed wrong.





[DBAL-600] Add support of joins in update statements when using DBAL QueryBuilder Created: 09/Sep/13  Updated: 23/Dec/13

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

Type: Improvement Priority: Major
Reporter: Konstantin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Comments   
Comment by Steve Müller [ 23/Dec/13 ]

This is tricky as UPDATE statements based on JOINs are not in the SQL standard and therefore the syntax and support differs alot throughout the vendors. But could be doable with some effort.





[DBAL-599] Add support of insert and insert select statements in DBAL QueryBuilder Created: 09/Sep/13  Updated: 25/Nov/13

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

Type: Improvement Priority: Major
Reporter: Konstantin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Reference
relates to DBAL-182 Insert and Merge Query Objects Open
relates to DBAL-320 allow SQL QueryBuilder to do INSERTS Resolved
is referenced by DBAL-636 QueryBuilder insert Resolved




[DBAL-587] Support for Triggers, Views, Procedures Created: 27/Aug/13  Updated: 27/Aug/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Schema should have support for triggers, views and stored procedures. Since this is not standardizable accross platforms easily, the idea is to allow arbitrary SQL DDL Statements to be registered on a Schema, maybe even qualified by platform.

$artifact = new SQLArtifact();
$artifact->setName('some_view_name');
$artifact->create('CREATE VIEW IF NOT EXISTS foo SELECT 1');
$artifact->drop('DROP VIEW foo');
$artifact->setPlatforms("mysql"); // accepts string or array, if nothing is set applies to ALL platforms.
$schema->addSQLArtifact($artifact);

During the SQL generation for the schema, the following will be appended to the currently generated SQL:

DROP VIEW foo;
CREATE VIEW IF NOT EXISTS foo SELECT 1

The drop part of the statement is always rendered before the create statement in the Create Schema Visitor. In the Drop schema listener only the drop part is used.






[DBAL-547] Evaluate moving away from prepared statements to sprintf() Created: 18/Jun/13  Updated: 18/Jun/13

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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We are using prepared statements and parsing on top at the moment to implement things like array param quoting and such.

We should evaluate if it makes sense to introduce a strategy for preparing/parsing queries and make sprintf() usage a default in 3.0 instead of using prepared statements. At least for MySQL the PHP Driver guys are arguing for this kind of processing for years.






[DBAL-390] Wrap SQL for Selects in an Object for Metadata? Created: 23/Nov/12  Updated: 23/Nov/12

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None





[DBAL-348] [GH-202] Fixed DBAL-139 Oracle's sequences with NOCACHE Created: 22/Sep/12  Updated: 22/Dec/13

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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 23/Sep/12 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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





[DBAL-324] SchemaManager should first look into comment instead of infer the type first. Created: 17/Aug/12  Updated: 03/Jan/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: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using schema tool, Doctrine tries to infer the Doctrine type via the mapped types in Platform.
It should first try to read from the comment; if found, ignore the Database type inference.



 Comments   
Comment by Benjamin Eberlei [ 29/Aug/12 ]

Why is this a bug? Can you say some more about why we need to do this and what error occurs?

Comment by Guilherme Blanco [ 29/Aug/12 ]

This issue is strictly correlated to the commit I've done here: https://github.com/doctrine/dbal/commit/e25c774dde971dc4afd40648e9ccd0af53b34ce9

Mainly, we may have legacy database that we do know how Doctrine should operate. Under this circumstance, we may want to add a comment to the field defining the Doctrine DBAL type.
Even though after doing this, Doctrine still complains (in my situation, a SET column type) that it's unable to handle this column type.

That happens because MySQL Schema Manager (and others) first looks for the column type:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L112
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L312
which automatically fails.

But if we first try to look for the commented data type:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L884
And forget about the rest if it finds one definition there, it would allow even unknown data types to be managed instead of forcing to define the DBAL Type compatible.

Comment by Steve Tauber [ 14/May/13 ]

This also applies for a type of yaml.
Example:

/** @Column(type="yaml") */
protected $data = array();

./scripts/doctrine orm:schema-tool:update --dump-sql
ALTER TABLE meta CHANGE data data LONGTEXT NOT NULL;

Very frustrating.... Might be related to http://www.doctrine-project.org/jira/browse/DBAL-42

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

Steve Tauber You have defined a custom data type. You need to override `Type::requiresSQLCommentHint()` to return true in your custom data type, otherwise Doctrine cannot infer the custom type mapping from the column comment and the comparator will always detect changes between Yaml and LONGTEXT. This is not directly related to this issue here I think.
Guilherme Blanco I don't really get the issue you describe here. Is it maybe fixed already? Otherwise can you maybe try to explain again so that I can fix that?





[DBAL-321] [GH-184] Added INSERT support to dbal QueryBuilder Created: 13/Aug/12  Updated: 20/Dec/13

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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

See also http://www.doctrine-project.org/jira/browse/DBAL-320
Please review and commit as fits.



 Comments   
Comment by Doctrine Bot [ 20/Dec/13 ]

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-294] [GH-163] [WIP] Upsert support protoype. Created: 29/Jun/12  Updated: 20/Dec/13

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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-76] PostgreSQL Platform list* SQL code is in need of serious love Created: 12/Dec/10  Updated: 08/Jun/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The Postgres Schema code is very hard to read and inconsistent across the board. Some use pg_class, some pg_tables. Namespaces /Schema are not always properly checked for. There should be a really unified way on how to approach schema query issues.



 Comments   
Comment by Denis [ 08/Jun/11 ]

I'm not sure what this ticket is about exactly, but...

"Namespaces /Schema are not always properly checked for."

Usually, one would not want to specify them and set the search_path instead. Or are you meaning the schema analysis queries used internally? (If so, yes, it kind of sucks in that case, but note that there are a bunch of *_is_visible() methods, e.g. pg_catalog.pg_table_is_visible(rel.oid) which will strip out invisible schemas directly. This may be simpler than injecting schema references all over the place in that it also processes permissions.)

Also, note that PG has a whole bunch of pg_catalog views, which are available in the information_schema.





[DBAL-31] Move Schema related Creation code from AbstractPlatform to AbstractSchemaManager Created: 04/Jul/10  Updated: 28/Dec/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Move Schema related Creation code from AbstractPlatform to AbstractSchemaManager



 Comments   
Comment by Benjamin Eberlei [ 08/Aug/10 ]

Scheduled for Beta4

Comment by Roman S. Borschel [ 16/Aug/10 ]

If this task is more complex and requires larger refactorings we can re-evaluate it in a post-2.0 release.

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

Benjamin Eberlei Do you still remember what is meant by this ticket? Could be solved already...





[DBAL-828] [GH-538] Json_Array: Convert database null to PHP null instead of empty array Created: 04/Mar/14  Updated: 24/Apr/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 localheinz:

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

Message:

Related to https://github.com/doctrine/doctrine2/pull/968.



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

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

Comment by Doctrine Bot [ 24/Apr/14 ]

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

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

To be addressed in 3.0. We cannot change the behaviour in 2.x for BC reasons.





[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-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-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-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-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-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-512] Update schema not working on MsSql due to no support for alter identity Created: 06/May/13  Updated: 16/Dec/13

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

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

Symfony 2.1, SQL Server 2008, driver: pdo_sqlsrv



 Description   

When running: php app/console doctrine:schema:update --force

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE tableName ALTER COLUMN id INT IDENTITY NOT NULL':

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Incorrect syntax near the keyword 'IDENTITY'.

According to this stackoverflow http://stackoverflow.com/a/1049305/1833322 MSSQL does not support this query.



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

Obviously SQL Server doesn't support this. So what solution would you expect here? IMO such a scenario should be avoided as there is no reasonable way to deal with changing identity columns. I guess most people are not even aware of this. The solutions available are very risky (creating new schema and then migrating data for example) and can take very long to be finished and is extremly error prone. I don't know if we should support one of those workarounds.

Comment by Flip [ 27/Nov/13 ]

The bug is about the SQL statement that does not work.
1. One solution could be to prevent generating this statement and issue a warning instead. (not preferred)

Two other solutions are mentioned in that Stackoverflow post I mentioned, namely:
2. Create a new table with identity & drop the existing table
3. Create a new column with identity & drop the existing column

That is just the way things have to be done in SQL Server (unfortunately), so it wouldn't be a workaround. I think this is a very reasonable way and in fact similar solutions to similar problems have already been implemented into Doctrine. See http://www.doctrine-project.org/blog/doctrine-2-4-released.html "ALTER TABLE support for SQLite (by hason) by creating new tables, moving all the data and then renaming."

Comment by Benjamin Eberlei [ 13/Dec/13 ]

Flip not many people actually use Sqlite in production, its more of a "play database" with Doctrine, wheras SQL Server carries much more weigh. I don't want to implement this kind of workaround, Steve Müller what do you think is safe here?

Comment by Flip [ 13/Dec/13 ]

Not to argue .. but it's not a workaround

Really .. if it is ever implemented it would have to be in a few steps because SQL Server does not accept this one-line command like that. So basically when you don't want this solution it means that will never be implemented.

Talking about safe .. mind that the safety should also be ensured in other area's like 1. don't run --force on a production database 2. make backups. So when regarding the safety it's a very narrow area to take a look at. The operation could be setup in such a way that if the new table/column could not be created then the old one doesn't get deleted. That way you have always the safety like a database transaction.

I guess no point in making a Proof of Concept, because the general outline of the problem is actually not that complicated ..

Thx guys for the input on this issue.

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

Benjamin Eberlei we could of course use one of the approaches Flip mentioned, but the question is what to do in case something goes wrong during one of the steps required to alter an IDENTITY column. If it is acceptable that there exist "dead" tables/columns in case something goes wrong, we could try implementing that.





[DBAL-994] [GH-682] [WIP] [DBAL-218] Add bulk insert query Created: 30/Sep/14  Updated: 30/Sep/14

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

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


 Description   

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

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

Message:

This is an approach to make use of database vendors' bulk row insert query syntax.
As the nature of bulk inserts usually is to insert a LOT of rows into a table (primarily from an external source), the implementation tries to focus on good performance and low memory consumption. It is NOT intended for `INSERT INTO ... SELECT ...` statement queries.

TODO:

  • Add an "executor" class that encapsulates the `BulkInsertQuery` object, adds options like bulk size and internally automatically evaluates the underlying platform's limits for a single `INSERT` statement and splits queries accordingly.
  • Evaluate platforms' max insert rows per `INSERT` statement and implement in platforms.
  • Add unit tests for quoted identifiers.
  • Add functional tests.

Future additions:

  • Add support for expressions.
  • Query builder (if there will be more bulk insert queries like `INSERT INTO ... SELECT ...`)?

Open for discussion. Ideas welcome!






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

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

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


 Description   

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

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

Message:

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

        1. Background

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

This results in the following scenario:

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

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

        1. Solution

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

So, this PR:

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

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

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

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

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

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

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

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

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

```

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

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

This is what should happen in each alter scenario:

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

This is what does happen today:

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


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

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





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

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

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

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

 Description   

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

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

Message:

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

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

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

I think that this implementation checks all the boxes:

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

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

What do you think?






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

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

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


 Description   

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

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

Message:

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



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

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





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

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

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


 Description   

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

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

Message:

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

Before:
``options=

{"where": "other_id IS NULL"}

``

After:
``options=

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

``

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

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

``






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

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

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


 Description   

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

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

Message:

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

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

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






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

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

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


 Description   

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

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

Message:

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






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

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

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

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

 Description   

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

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

Message:

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

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

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

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



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

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





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

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

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


 Description   

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

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

Message:

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

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



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

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





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

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

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


 Description   

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

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

Message:

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

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

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



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

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





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

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

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


 Description   

Implemented support for Interbase/Firebird dialects






[DBAL-602] Deprecate Migrations in favor of stable tools Created: 12/Sep/13  Updated: 04/Dec/14

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DBAL-603 DbDeploy Support Sub-task Open Benjamin Eberlei  
DBAL-604 Liquibase Support Sub-task Open Benjamin Eberlei  
DBAL-605 Phinx Support Sub-task Open Benjamin Eberlei  

 Description   

The Migrations project is very big and currently unmaintained, even if there is definately need for a solution of the migration problem.

The idea would be introduce a subcomponent in DBAL that delegates this to proven tools (DbDeploy and Liquibase, and Phinx for PHP based).

The functionality Doctrine should provide is integration with the \Doctrine\DBAL\Schema API. Three operations come to mind:

  • status - What version are we? Do we need to execute more versions?
  • migrate - Execute the migration tool
  • create-migration - Create a new migration file of the underlying platform.

The last operation needs to check if no versions need to be applied at the moment.

interface MigrationTool
{
   /** @return MigrationCurrentStatus */
   public function getStatus();

   /** @return MigrationPerformedStatus */
   public function migrate($toVersion = null);

   /** @return MigrationRolledBackStatus */
   public function rollback($toVersion = null);

   /** @return MigrationCreatedStatus */
   public function create(Schema $toSchema);
}

Every tool implements this interface and then we need 3 new commands for "status", "migrate" and "rollback". The "create" command can only be implemented in the context of the ORM.



 Comments   
Comment by Christophe Coevoet [ 12/Sep/13 ]

What is the idea here ?

I don't agree about removing the Migrations project in favor of using only the schema diff tool (which we already have as a command in the ORM btw). Migrating is not only about updating the schema. It also requires migrating data. Otherwise, it is not safe to use in production. This is why the

{doctrine:schema:update}

command displays a warning before running.
A good example is adding a new non-nullable unique field. Applying the schema update works on an empty DB but fails when the table already contains data.

Comment by Benjamin Eberlei [ 12/Sep/13 ]

Christophe Coevoet The idea is not to keep only ORM Schema-Tool, which is really only a Dev-Tool. We would rather add support for DbDeploy, Liquibase and Phinx into DBAL via some integration sub-component and using DBAL\Schema to create migration files for their formats.

Comment by Miha Vrhovnik [ 04/Jan/14 ]

There is also http://dbv.vizuina.com/

Comment by Jonathan Cardoso Machado [ 31/Jan/14 ]

The command line support is going to stay right? The idea here is to use third party deploy framework, but with specific bindings to use with Doctrine, Am I right?





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-603] DbDeploy Support Created: 27/Feb/13  Updated: 12/Sep/13

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   
  • DbDeploy Diff Generation
  • Schema Serialization
  • SchemaTool gets new event when diff is applied, then you can update a "stable" schema xml. On Generation new db deploy script, use current schema vs stable schema vom disc.





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-605] Phinx Support Created: 12/Sep/13  Updated: 18/Sep/13

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Comments   
Comment by Rob Morgan [ 18/Sep/13 ]

Hi Guys, I'm the lead developer for Phinx. Happy to give support here if needed.

Rob





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-604] Liquibase Support Created: 12/Sep/13  Updated: 04/Dec/14

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None





[DBAL-221] Schema toSQL() and toDropSQL() both need to delegete creation/drop of schema-level elements Created: 13/Feb/12  Updated: 04/Dec/14

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

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


 Description   

The following schema-level changes have to be done before tables are created:

  • create Schema (PGSQL, MySQL, ...)
  • Create Federations (Azure)
  • Create Types (PGSQL, Oracle, ...)
  • Create Views, Stored Procedures, Triggers

We should add the following APIs:

array $sql AbstractPlatform::getCreateSchemaAdditionalStatements(Schema $schema);
$object = new SQLObject($sqlUpCommand, $sqlDropCommand);
$schema->addSQLObject($object);





[DBAL-225] Add events for onBeginTransaction, onCommit, onCommitFailure Created: 13/Feb/12  Updated: 04/Dec/14

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

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


 Description   

Allow to switch a CommitFailure into a successful event.

This could be done by saving all insert/update/delete statements starting from begin transaction and then replaying them N-times until success is achieved.






[DBAL-182] Insert and Merge Query Objects Created: 18/Nov/11  Updated: 04/Dec/14

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

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

Issue Links:
Reference
relates to DBAL-320 allow SQL QueryBuilder to do INSERTS Resolved
is referenced by DBAL-599 Add support of insert and insert sele... Open
is referenced by DBAL-636 QueryBuilder insert Resolved

 Description   

We are missing Insert and Merge Query Objects.

See Drupal DBTNG:

Merge: http://drupal.org/node/310085
Insert: http://drupal.org/node/310079



 Comments   
Comment by Benjamin Eberlei [ 18/Nov/11 ]

From the first glance: Drupal API has some problems in that it assumes literal values are the default, which makes working with them simple if no expression is necessary. But inconsistent otherwise.

Implementation Details:

  • Difference compared to QueryBuilder is that these objects are no builders, but actually executors.
  • Don't assume Literals
  • Creation is delegated to Platform (Runtime API of a Vendor)
{conn}
$conn->createInsertQuery();
$conn->createMergeQuery();{conn}

Sample API:

$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->values(array('?', '?'))->(array(1, 2))->execute();
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->params(array(1, 2))->execute(); // values(?, ?) is implicit.
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->params(array('NOW()', '1'))->execute(); // if no "params" set assume execute once.
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->value('foo', 'NOW())->params(array(1))->params(array(2))->execute();
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->select($queryBuilder)->execute();

Merge: I dont know yet:

problem i see here is that people mistake values() for a "safe" method and pass values in there that should be quoted instead.





[DBAL-163] Upsert support in DBAL Created: 10/Sep/11  Updated: 04/Dec/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Upsert support in DBAL (replace, insert into usw..)



 Comments   
Comment by Miha Vrhovnik [ 11/Jun/12 ]

FYI: http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/





[DBAL-218] Add Object for BulkInsert Abstraction Created: 05/Feb/12  Updated: 04/Dec/14

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

Type: Task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None





[DBAL-217] Introduction Interface for Connection Created: 05/Feb/12  Updated: 04/Dec/14

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

Type: Task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None





[DBAL-1062] upgrade from v2.4.3 to v2.5.0 is forcing recreating Indexes making Doctrine unusable Created: 05/Dec/14  Updated: 12/Dec/14

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

Type: Bug Priority: Major
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: index
Environment:

any



 Description   

after executing 'composer update' i was upgraded to dbal v2.5.0
(im using "doctrine/orm": "~2.2,>=2.2.3" in composer.json)
im using Symfony 2.6.*

now when i try 'app/console doctrine:schema:update --dump-sql' i see that doctrine wants to recreate indexes on some tables for no practical reason
nothing changed in the code.

example:
DROP INDEX idx_a604da13a76ed395 ON table1;
CREATE INDEX IDX_B7E704F0A76ED395 ON table1 (user_id);
DROP INDEX uniq_b3319c7d77153098 ON table2;
CREATE UNIQUE INDEX UNIQ_C984F95777153098 ON table2 (code);

however when i try to execute this update, im getting this error:
General error: 1553 Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

this essentially prevents me from using automatic doctrine database mapping or using migration tools.



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

Downgraded to "Major", as this doesn't prevent usage of the DBAL at runtime.

You can still upgrade those indexes manually after having removed the FKs (to re-add them later on).

Seems like a case sensitivity issue of your setup: consider adding environment details.

Comment by Steve Müller [ 05/Dec/14 ]

Which database vendor are you using? Also interestingly the indexes get recreated with a different name. Thought of case sensitivity, too. I think the comparator nevertheless has to be adjusted to compare with identical case on index names.

Comment by gondo [ 05/Dec/14 ]

well it IS preventing me from using doctrine as it is.
i just downgraded dbal to v2.4.3 by adding "doctrine/dbal": "2.4.*", to my composer.js and everything is working fine. by that i mean, no commands to drop and create indexes.

im using mysql Ver 14.14 Distrib 5.6.21, for osx10.10 (x86_64) using EditLine wrapper

im developoing on OSX 10.10 and production is running CentOS.
i know that OSX is using case insensitive file system (i had to deal with it in the past when i was deploying to production)
but this time there is NO change in my code. zero. nothing.

if there was case sensitivity changes in dbal itself, that might be the problem, however that is nothing i can fix.

i would love to upgrade those indexes manualy, however i have no idea how to.
should i change something in the code? indexes were created and named by doctrine, not by me.
if you recommend updating database, that seems to be failing. i assume dropping indexes on live data might cause problems.
or is it safe to just drop and create these indexes in mysql cmd?

Comment by gondo [ 05/Dec/14 ]

i can not drop those indexes directly in mysql, im getting erros:
ERROR 1553 (HY000): Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

Comment by Steve Müller [ 05/Dec/14 ]

okay just checked, casing is not a problem as identifiers will be lowercased automatically in Doctrine\DBAL\Schema\Table for comparison.
Need further information about the underlying database being used...

Comment by Steve Müller [ 05/Dec/14 ]

gondo please for now don't try to solve the issue automatically because it looks like a real issue we need to figure out. Otherwise there will be little chance we get to know the real cause of the issue...

Comment by gondo [ 05/Dec/14 ]

@Steve Müller for now i've solved it by downgrading dbal to v2.4.*
do you need some more information from me?
unfortunately i can't give you all the code, company policy + its quite big. but i can dump you database schemas and entity declarations of affected tables if that will help. please let me know.

Comment by Steve Müller [ 05/Dec/14 ]

Hmm cannot reproduce the problem. What I did:

composer create-project symfony/framework-standard-edition path/

then added 'doctrine/dbal": "2.4.*"' to composer.json

composer install

then created entity with unique column name (to force auto index generation)

php app/console doctrine:database:create
php app/console doctrine:schema:create

then changed 'doctrine/dbal": "2.4."' to 'doctrine/dbal": "2.5."' in composer.json

php app/console doctrine:schema:update --force
Nothing to update - your database is already in sync with the current entity metadata.

Tried that with pdo_mysql on ubuntu 14.04 x86_64.

Comment by gondo [ 05/Dec/14 ]

were you creating some tables with foreign keys?

Comment by gondo [ 05/Dec/14 ]

here is the list of all indexes what tries to be recreated:
http://pastebin.com/nFYp6pnp

here are the definitions of some entities + their schemas and indexes from mysql:
notification_channel
http://pastebin.com/EfkcyUnf
http://pastebin.com/Ngd1Lkbe

online_payment_option
http://pastebin.com/R5waCF35
http://pastebin.com/ti4TzyKX

user_settings
http://pastebin.com/gxed5kjY
http://pastebin.com/EiCBWKNQ

i've also tried to specify index with custom name as per http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-index
to prevent this index recreation but without no luck, it was ignored.
i've tried to change the definition of `online_payment_option` table like this:
@ORM\Table(name="online_payment_option", options=

{"collate"="utf8_unicode_ci", "charset"="utf8"}

, indexes={@ORM\Index(name="TEST", columns=

{"code"}

)})
but after trying schema:update im still getting the same output http://pastebin.com/nFYp6pnp

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

Okay I think I get the problem now. I don't get any suggested update statements when upgrading from a DBAL 2.4 created schema to DBAL 2.5.
I assume this is because even in DBAL 2.4 the indexes are created with the name your update command suggests. For example:

DROP INDEX idx_a604da13a76ed395 ON notification_channel;
CREATE INDEX IDX_B7E704F0A76ED395 ON notification_channel (user_id);

You have an index named idx_a604da13a76ed395 in your database, the index name DBAL generates is IDX_B7E704F0A76ED395. Even in 2.4 this is the name that is generated by DBAL. The reason why you get those update statements is because index names are compared since DBAL 2.5 as part of the new index renaming feature.
I guess that the index name generation has changed in an earlier version of DBAL (can't prove that right now). So you probably created the index with a much earlier DBAL version back then and now it wants to rename it. This should be a one time "upgrade" step.
The reason why manually defining an index in your entity with a custom name has no effect is because ORM's schema tool prefers auto generated indexes over custom indexes if both fullfill the same criteria. This is something to be fixed in ORM then.
The foreign key problem is indeed something we have to deal with in DBAL. The update schema command should create SQL to first drop FKs, then rename indexes and afterwards recreate FKs again.
Hope that helps for now. Sorry for the upgrade circumstances...

Comment by gondo [ 12/Dec/14 ]

thank you very much for looking into this and spending time on it!
it is very likely that those indexes were created in older version, however I'm 100% that it is not older than 1 year.

if i understand correctly, there are several things what needs to be fixed (manual overwriting of indexes and generating proper update schema command)

is this something what will be fixed? or does this fall into "edge case" bucket and will be left until more people experience same problem?
so far I'm fine staying on 2.4.3 but eventually i would like to upgrade. if the fix is planned, i can wait. if not, than i can create manual update now.

thanks one more time

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

I am already on that foreign key issue. As soon as that is fixed, the generated update SQL should be valid so that it can safely be run and you don't need to update your index names manually then. As what the manual index preference is concerned that needs to be fixed in ORM. I might also have a look into this issue afterwards. I think it won't take long until DBAL 2.5.1 as there is another critical issue that needs to be adressed sonner than later.
With 2.5.1 you should be safe to update your schema automatically.

Comment by gondo [ 12/Dec/14 ]

perfect!
thats much sooner than i expected
thanks again





[DBAL-1074] [GH-743] Add failing unit test related to DBAL-1063 Created: 14/Dec/14  Updated: 14/Dec/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 flack:

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

Message:

I am not 100% sure, but I think the behavior exposed by this test is one of the factors in DBAL-1063. But even if it wasn't, it is still very confusing that `Table::getIndexes` doesn't return the same thing as `SchemaManager::listTableIndexes` when they are both called on the same table.

I've written the test against the MySQL SM, but I suspect the same might happen with other platforms as well






[DBAL-1063] Exceptions from SchemaTool when running with DBAL 2.5.0 Created: 06/Dec/14  Updated: 15/Dec/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: flack Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm not entirely sure it it is related to DBAL-1062, but I'm seeing some similar problems since updating to 2.5.0. The problem I'm having occurs only once per table, and only for some tables, so it is kind of hard to debug. What I've found out so far is that it happens when I manually define an index on a column which I name f.x. 'colname_idx', and then later Doctrine wants to add an index to the column automatically (e.g. when it is an association field), in which case it generates an index name like 'IDX_CF2713FD16F4F95B'.

An index with this name already exists (from the last run of the SchemaTool, presumably). The isFullfilledBy function in Doctrine\DBAL\Platforms\AbstractPlatform\Index detects that the both the manually-named index and the automatically-named one are identical and thus ignores them in Doctrine\DBAL\Schema\Table::_addIndex.

When the schema read from the database is compared to the one generated from metadata in Doctrine\DBAL\Schema\Comparator::diffTable, $table1 will list 'colname_idx' and the one from $table2 will say 'IDX_CF2713FD16F4F95B'. So it will be counted as a rename, and the rename SQL (for mysql at least) is

DROP INDEX colname_idx ON tablename
CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)

But as mentioned before, IDX_CF2713FD16F4F95B already exists, so I get

  [Doctrine\DBAL\Exception\DriverException]                                                          
  An exception occurred while executing 'CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)':          
  SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'IDX_CF2713FD16F4F95B'

Since the DROP statement before was executed successfully, on the next SchemaTool run, the existing index will be detected correctly for $table1, and thus no rename is issued.



 Comments   
Comment by Steve Müller [ 08/Dec/14 ]

From a first glance this issue is caused by ORM's schema tool which is creating indexes implicitly for unique columns and associations. Seems it doesn't play well with the new index renaming feature from DBAL 2.5 if you also define indexes explicitly that also fullfill those auto generated ones.
Maybe we have to asjust the schema tool to make a certain preference of explicitly defined indexes over auto generated ones if both fullfill the same criteria.

Comment by flack [ 08/Dec/14 ]

Well, making the schema tool smarter is certainly a good idea, since in 2.4 it created duplicate indexes (different name, same function) if I understood your theory correctly.

But there are some things on the DBAL side that I wonder about, e.g. shouldn't dbal do a sanity check before renaming? Or is there one that doesn't trigger because it cannot detect that an index with the target name already exists?

As far as I understood it, the schema read from the database was missing the one index (auto-generated one by SchemaTool), because Doctrine\DBAL\Schema\Table::_addIndex refused to add it on the grounds that it isFullfilledBy the manually-created index. This sounds like a very valid optimization for the case where I plan to write a schema to the database, but it is not at all helpful when creating a representation of an existing database. So I wonder if this case shouldn't be handled differently.

The other thing I'm still unclear about is why the second schema (the one coming from the driver) has the autogenerated index instead of the manual one. I suppose it could be a timing issue, but if the driver and the schematool both were to call _addIndex in the same order, the issue wouldn't even occur. Which might make it difficult to write a unit test for it

Comment by Steve Müller [ 09/Dec/14 ]

flack I did not test anything about this issue yet. It's all just speculation at the moment. What we'll have to do is try reproducing it in a test case. I would propose adding a test case to ORM first as this is your main entry point. Would be awesome if you could PR such a test case that reveals the issue then we can make further inspections. Still not sure whether it's a DBAL or ORM issue or maybe even both...

Comment by flack [ 15/Dec/14 ]

I've added two tests now:

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

The first one shows a discrepancy between Table::getIndexes and SchemaManager::listTableIndexes (which might be the root cause of the problem), and the second one reproduces the exception mentioned above.

BTW: Is there a way to make Jira recognize that a PR belongs to an already existing ticket? Right now, it always seems to create a new issue for each pull request





[DBAL-1076] [GH-745] Added doModifyLimitQuery for SQLServer2012Platform that uses OFFSET... FETCH Created: 16/Dec/14  Updated: 16/Dec/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/745

Message:

SQL Server 2012 introduced new syntax for paging records using the OFFSET... FETCH clause. See http://technet.microsoft.com/en-us/library/gg699618%28v=sql.110%29.aspx for details on the specification.

This pull request:

  • Adds doModifyLimitQuery specific to SQLServer2012Platform, using OFFSET ... FETCH instead of ROW_NUMBER() OVER(blah blah)
  • Duplicates tests from SQLServerPlatformTest, using simpler OFFSET ... FETCH syntax

This version of doModifyLimitQuery will be much more robust than the one for SQLServer 2008 and below.






[DBAL-1079] [GH-747] minor phpdoc fixes in the schema files Created: 16/Dec/14  Updated: 16/Dec/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 acrobat:

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

Message:

Some minor phpcs fixes in the dbal schema files






[DBAL-1081] Paginator - Query Limit for SQL Server - SqlServerPlatform.php Created: 16/Dec/14  Updated: 18/Dec/14

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

Type: Bug Priority: Major
Reporter: Maciej Grajcarek Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, dql, orderBy, sqlserver
Environment:

Windows



 Description   

Hi!
I have a problem with Query results limit when ordering by SUM of a field.

My query looks like this:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

First I was catching following error:
message: "[Syntax Error] line 0, col 395: Error: Expected known function, got 'SUM'"
class: Doctrine\ORM\Query\QueryException

It only accourse if SUM is used in ORDER BY clause.

I have registered new class Sum which extends FunctionNode.

Now, query is build and executed but it has an error:

'SELECT * FROM 
     (SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY value) DESC) AS doctrine_rownum FROM yellowpage_keywords y0_ INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id INNER JOIN listings l2_ ON y1_.listing_id = l2_.id WHERE l2_.customer_id = ? AND y0_.origin_date >= ? AND y0_.origin_date <= ? GROUP BY y0_.name_crc, y0_.name) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10 ORDER BY doctrine_rownum' with params ["111", "2013-01-01 00:00:00.000000", "2014-12-31 23:59:59.000000"]

The line :

ROW_NUMBER() OVER (ORDER BY value) DESC)

should look like

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC)

In doModifyLimitQuery method I have modified:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', $column['table'], $column['column']);

to:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', str_replace('(', '\(', $column['table']), str_replace(')', '\)', $column['column']));

Now preg_match founds matching strings and OVER part of query is build correctly.

I checked other issues about this problem (which are marked as already fixed) and I have no idea why it's not working for me.

Thanks in advance!



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

Seems like a bit of information is missing: Is this issue related to the paginator API or not?

Comment by Maciej Grajcarek [ 17/Dec/14 ]

First of all - thank you for formatting my issue.
Secondly yes - issue is directly connected with paginator API.

Here is a code which should help you to replicate the problem:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

        $dql = $this->getEntityManager()->createQuery($query);
        $dql
            ->setParameter('customerId', $customerId)
            ->setParameter('dateFrom', $dateFrom)
            ->setParameter('dateTo', $dateTo);
        $dql->setMaxResults(10);    

        $keywords = $dql->getArrayResult(); 
Comment by Marco Pivetta [ 17/Dec/14 ]

That doesn't involve the paginator, just DQL.

SUM() and computed values are not supported in the ORDER BY clause: you have to select them first. Try:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY total DESC
Comment by Maciej Grajcarek [ 18/Dec/14 ]

If I will do it, it will result in a following query:

SELECT *
FROM (
	SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum 
	FROM yellowpage_keywords y0_
	INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id
	INNER JOIN listings l2_ ON y1_.listing_id = l2_.id
	WHERE l2_.customer_id = 111
		AND y0_.origin_date >= '2014-01-01'
		AND y0_.origin_date <= '2014-12-01'
	GROUP BY y0_.name_crc, y0_.name
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 10
ORDER BY doctrine_rownum

It's an incorrect query for an SQL Server. Take a look on this part:

ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum

SQL Server do not support aliasing in OVER clause.

It should look like this, to work:

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC) AS doctrine_rownum

It looks like this is the copy of this issue: http://www.doctrine-project.org/jira/browse/DBAL-788
I'm on doctrine version 2.5 which has patch from that issue included, but I have no idea why it's not working for me.





[DBAL-1086] [GH-750] Store the parameters of the chosen connection when using Master/Slave. Created: 19/Dec/14  Updated: 19/Dec/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 xrash:

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

Message:

When using the MasterSlaveConnection, the internal parameters array has a different structure than the usual Connection. This can cause the following methods to fail: getHost(), getPort(), getUsername() and getPassword().

I changed the MasterSlaveConnection so that it stores the parameters of the chosen connection in a private property. With this change, the methods that used to fail can now retrieve the configuration for the actual chosen connection, which is, in my opinion, clearly the expected behavior.

I chose to create a new private property in MasterSlaveConnection instead of inherit the $_params from Connection in order to not cause any confusion by having two different array structures in the same variable at different situations.

I also expanded the tests for this case.






[DBAL-1088] [GH-752] Fix error handling restore Created: 19/Dec/14  Updated: 19/Dec/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 nicolas-grekas:

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

Message:

PHP already handles an internal stack of error handlers






[DBAL-1083] [GH-749] [DBAL-1082] Fix SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 18/Dec/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 dchesterton:

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

Message:






[DBAL-1084] MySQL DateTime fractional seconds exception Created: 18/Dec/14  Updated: 19/Dec/14

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

Type: New Feature Priority: Major
Reporter: Jachim Coudenys Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL 5.6.4+



 Description   

Since MySQL 5.6.4 it is possible to include fractional seconds in datetime/timestamp fields.

Doctrine cannot handle this at the moment, and it is not clear how this can be resolved.

Doctrine\DBAL\Types\ConversionException(#67): Could not convert database value "2014-12-16 17:06:38.385" to Doctrine Type datetime. Expected format: Y-m-d H:i:s
  #0 /var/www/vendor/doctrine/dbal/lib/Doctrine/DBAL/Types/DateTimeType.php(67): Doctrine\DBAL\Types\ConversionException::conversionFailedFormat('2014-12-16 17:0...', 'datetime', 'Y-m-d H:i:s')
  #1 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(330): Doctrine\DBAL\Types\DateTimeType->convertToPHPValue('2014-12-16 17:0...', Object(Doctrine\DBAL\Platforms\MySqlPlatform))
  #2 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(359): Doctrine\ORM\Internal\Hydration\AbstractHydrator->gatherRowData(Array, Array, Array, Array)
  #3 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(179): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData(Array, Array, Array)
  #4 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(140): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData()
  #5 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(804): Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll(Object(Doctrine\DBAL\Driver\PDOStatement), Object(Doctrine\ORM\Query\ResultSetMapping), Array)
  #6 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(574): Doctrine\ORM\AbstractQuery->execute(NULL, 1)
  #7 /var/www/index.php(142): Doctrine\ORM\AbstractQuery->getResult()

The solution for MsSQL (see DBAL-860) cannot be used, because the fractional seconds definition can be different across fields:

  `insert` timestamp NULL DEFAULT NULL,
  `update` timestamp(3) NULL DEFAULT NULL,
  `delete` timestamp(5) NULL DEFAULT NULL,

My current approach is to create a custom type, but I would like to create a solution in Doctrine.

Any thoughts on this?



 Comments   
Comment by Marco Pivetta [ 18/Dec/14 ]

We don't currently support this nor can support a change in the DateTime type in 2.x. If you want support for this, then I suggest using a custom type (as you are doing) or proposing something new for 3.x

Comment by Jachim Coudenys [ 19/Dec/14 ]

For anyone that is having the same issue, I've added my version of the custom mapping in a Github Gist.





[DBAL-1089] [GH-753] Add a unit test for broken backslashes on MySQL in LIKE Created: 19/Dec/14  Updated: 19/Dec/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: 1
Labels: None


 Description   

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

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

Message:






[DBAL-837] Cannot drop index needed in a foreign key constraint Created: 17/Mar/14  Updated: 17/Mar/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: Cliff Odijk Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MariaDB version 10.0.7
InnoDB version 5.6.10
doctrine/orm version v2.4.1
doctrine/dbal version v2.4.2


Issue Links:
Reference
relates to DBAL-732 MySQL 5.6 - Cannot change column 'fkP... Open

 Description   

I'm trying to remove an relation from an entity and i'm getting an error that it could not be executed. After testing it, it's missing the DROP FOREIGN KEY query.

The generated SQL is:

DROP INDEX IDX_DCE815B325C79A8C ON moveMembers;
ALTER TABLE moveMembers DROP fkAccessId;

When I use --force to execute it I get the following error:

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'DROP INDEX IDX_DCE815B325C79A8C ON moveMembers':

SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint

[PDOException]
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint



 Comments   
Comment by Cliff Odijk [ 17/Mar/14 ]

Maybe related to DBAL-732?





[DBAL-631] NuoDB compatibility Created: 15/Oct/13  Updated: 15/Oct/13

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

Type: Improvement Priority: Minor
Reporter: Pierre Bonneau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello,

I'm looking for a scalable SQL database, and I found nuoDB(old nimbus DB) that seems to do the job on paper.
My company tend to encourage us to move to many small VM architecture in place of large machines.

I wanted to know if such a DB engine was going to be supported in the near future, or if it was now.
For what I saw, the only really scalable solution I have now is nosql DB as mongo DB with doctrine.
As Doctrine is a requirment on our application, I was condering if you had any feedback for us on this subject.

Best regards, and thank you for your work.

Pierre Bonneau



 Comments   
Comment by Christophe Coevoet [ 15/Oct/13 ]

The best way to have NuoDB support in DBAL is probably to contribute it.
Introducing new drivers is best done by people using them (because they actually need it, and because they can more easily test them)

You will need to provide 3 classes (and their tests):

Comment by Pierre Bonneau [ 15/Oct/13 ]

Hello,

I already asked the question to NuoDB company, waiting their answer.
I'm absolutly not familiar with it, so I'm not very confident in the fact I would be able to provide a correct interface for this server.

I read mysql driver, shema and platform as an example. Driver and shema development should be dueable... but platform is totally out of my scope / scope... It would require a good knowledge of the database, and honnestly, I need only to perform 3 operations on it : INSERT / UPDATE and SELECT... without even a join. Would it be possible to let the other method empty and to let the community fill the blank ?

Thank you,
Pierre

Comment by Christophe Coevoet [ 15/Oct/13 ]

unfortunately, you need more than this in case you are using the ORM, because the ORM needs more methods from the platform (many of them has been added based on the needs of the ORM). However, the nuodb doc should only implementing these methods: doc.nuodb.com/display/doc/SQL+Reference

Comment by Pierre Bonneau [ 15/Oct/13 ]

Hello,

Thank you for your answer...

If we want to be compliant to Doctrine, is there a number of method that are required, and some other that are usefull?
I mean I can implement the method, but do nothing in some of them. The next user who need more will develop the module, or we will do later if needed.

The idea for me is to lower the cost, and to not pay on my project budget the entire connectivity...
I'm not againts speding 3-5 man day in this subject, but more will be an issue regarding the total amount of day I have on the project.

Pierre





[DBAL-372] Add SQL parser Created: 25/Oct/12  Updated: 25/Oct/12

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: Martin Hasoň Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It is useful for create sql highlighter. See https://github.com/doctrine/DoctrineBundle/pull/117 or https://github.com/doctrine/DoctrineBundle/issues/107






[DBAL-319] Doctrine\DBAL\Types\Type Created: 12/Aug/12  Updated: 22/Dec/13

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

Type: Improvement Priority: Minor
Reporter: Till Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The API could be improved in the next major release:

  • Type::add() instead of addType()
  • Type::isRegistered() instead of hasType() (has sounds weird)

Etc.. I think the 'type' in the methods is redundant since Type is already the object I am dealing with.

I'd also like a remove() method to unregister a type at runtime. Would make testing a little easier and I don't have to check with hasType() etc..



 Comments   
Comment by Marco Pivetta [ 12/Aug/12 ]

I don't think those namings are really important.
There's one major change to do, which is to somehow get rid of the staticness of the `Doctrine\DBAL\Types\Type` class, and it is not a simple task.
It would also be interesting to set the type objects manually, such as a database `password` type that does encryption/decryption based on a given service. That cannot be done without staticness right now, which renders two different connections requiring the same functionality but with different parameters very difficult.

Comment by Till [ 12/Aug/12 ]

I agree on the static. But I'd also like the API to be cleaned up and the remove method.

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

API cleanup and staticness can be addressed in 3.0 for the first time. Otherwise we cannot keep BC. You can use Doctrine\DBAL\Types\Type::overrideType('someType', null); as a workaround for removing a type from the registry.





[DBAL-292] Multiple use of named parameter doesn't work Created: 12/Jun/12  Updated: 28/Dec/13

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

Type: Bug Priority: Minor
Reporter: Jürgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

IIS 7.5, MS-SQL-Server 2005, PHP 5.4.0



 Description   

In the example in the documentation http://doctrine-dbal.readthedocs.org/en/2.0.x/reference/data-retrieval-and-manipulation.html#dynamic-parameters-and-prepared-statements there is the following example:

$sql = "SELECT * FROM users WHERE name = :name OR username = :name";
$stmt = $conn->prepare($sql);
$stmt->bindValue("name", $name);
$stmt->execute();

When I try this example using pdo_sqlsrv I get the following error:
PDOException: SQLSTATE[07002]: [Microsoft][SQL Server Native Client 11.0]COUNT field incorrect or syntax error

When I use instead the parameters name1 and name2 the query works as expected.



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Are you sure you were using the 2.2.2 version of the ORM? Can you try to reproduce this with the latest master?

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

Jürgen ping. I cannot reproduce this error, either. Can you please try to reproduce this with the latest master branch? Otherwise I will close this ticket.





[DBAL-180] Documentation states that Doctrine 'decimal' (DecimalType) is mapped to PHP 'double', however, string is returned Created: 11/Nov/11  Updated: 28/Dec/13

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

Type: Documentation Priority: Minor
Reporter: Menno Holtkamp Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

At http://www.doctrine-project.org/docs/orm/2.1/en/reference/basic-mapping.html#doctrine-mapping-types, it is stated that:

"decimal: Type that maps an SQL DECIMAL to a PHP double."

However, in the commit history, we can see that the casting to a float is removed: https://github.com/doctrine/dbal/commits/master/lib/Doctrine/DBAL/Types/DecimalType.php. Casting to a double is not possible in PHP?This seems to result in a float as well, that is probably why it was removed.

I found this out when using PHP's 'is_double()' function (alias of is_float()) to check whether a decimal property was set or not.

Suggestion is to either:

  • cast to a double (which seems not possible)
  • cast to a float (why was this removed?)
  • do nothing to the code, update documentation that string is returned.

In my check function I guess I will use the is_numeric() function.



 Comments   
Comment by Roel Harbers [ 19/Mar/12 ]

I would strongly suggest to leave the behaviour as-is, and fix the documentation, because of all the trouble associated with floating point and rounding. People use the DECIMAL type to prevent those issues, so having the ORM convert it to floating point again would be pretty bad.

Comment by Patrick McDougle [ 26/Apr/12 ]

I have submitted a pull request on this issue on github. Hopefully the doc will be updated soon so other people don't expect the wrong behavior!

https://github.com/doctrine/orm-documentation/pull/93

Mods, this issue can probably be closed.

Comment by Oleg Namaka [ 24/May/12 ]

Leaving decimal values as strings creates another issue with unnecessary entity updates because old and new same values have different types: old value is always the string type, the new one - decimal. If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity. This is plainly wrong IMHO.

Comment by karlie verkest [ 20/Dec/12 ]

There may be other issues around comparison. I'd rather be comparing numeric types than strings when comparing "decimal" values.

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

I don't think we can fix this in DBAL. We should leave the decimal values retrieved from database as string for the obvious conversion problems. AFAIK the documentation in ORM has also been updated. Don't know about ORM issues with entity updates, but I don't see any further todo here in DBAL. Can this ticket be closed?

Comment by Oleg Namaka [ 28/Dec/13 ]

@Steve Muller, is it feasible to change the way decimal values are compared from strict === to == to mitigate the issue with unnecessary updates:

If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity.

This is a very serious Doctrine shortcoming as for every single entity that has at least one decimal field with no real value changes updates still will be issued.

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

Oleg Namaka I understand that. But IMO this is an issue that has to be adressed in ORM because casting the values in the DBAL type breaks the precision/correctness of the original database value in some circumstances. Therefore the only possible solution can be to fix this in ORM IMO.





[DBAL-179] SQLLogger API improvement: log rows affected Created: 10/Nov/11  Updated: 10/Nov/11

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

Type: Improvement Priority: Minor
Reporter: Howard Ha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

A small suggestion. It is useful in our application to log the affected rows in queries in order to make it easier to trace what queries did what. I think a simple way to enable this in the SQLLogger is to modify the stopQuery() interface to receive an option rowcount parameter.






[DBAL-150] noSQL Shema Management Created: 21/Aug/11  Updated: 21/Aug/11

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

Type: New Feature Priority: Minor
Reporter: Alexey Shatunov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

all



 Description   

I have a few ideas to improve DBAL and ORM management for php:
1. Reading if needed ORM schemas definitions from YAML(existing plugin)
2. Then migration it into the one of NoSQL databases(such as MongoDB or Memcache/MemcacheDB)
3. Creating transactional temporary-changes data layer in NoSQL for a current-changes due the webapp launch and running for each run
4. Periodically migrations of a current changes with migration script into RDB(for example by cron)

So we get:
Fast automatic shemas management(Symphony users - I say you "haha" because you have to do some unuseful things like "doctrine:build-schema" etc)
All advantages of RDB (like JOINS) in a data extraction
Full-independence in data changing due to webapp launch(and no transactions are needed) in the current NoSQL data-layer
Low load to the server because after extration we have a lazy return data into the RDB
In feature a simple caching any fast-changed data into NoSQL

What do you thinking about it?






[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-732] MySQL 5.6 - Cannot change column 'fkProjectId': used in a foreign key constraint Created: 24/Dec/13  Updated: 18/Mar/14

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

Type: Bug Priority: Minor
Reporter: Cliff Odijk Assignee: Steve Müller
Resolution: Unresolved Votes: 2
Labels: None

Issue Links:
Reference
is referenced by DBAL-837 Cannot drop index needed in a foreign... Open

 Description   

I'm using doctrine migrations to change a null field to a not null field. MySQL 5.6 is strict on altering tables with foreign key constraint's.

Generated SQL

ALTER TABLE badges CHANGE fkProjectId fkProjectId INT NOT NULL

Result in the following error

Cannot change column 'fkProjectId': used in a foreign key constraint 'FK_1483A5E9F28AE4EA'

More info:

As of 5.6.7, the server prohibits changes to foreign key columns with the potential to cause loss of referential integrity. A workaround is to use ALTER TABLE ... DROP FOREIGN KEY before changing the column definition and ALTER TABLE ... ADD FOREIGN KEY afterward.

Original issue:



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

Cliff Odijk what versions of DBAL/ORM are affected by the bug?

Comment by Cliff Odijk [ 24/Dec/13 ]

Doctrine 2.3.4 / 2a37b007dda8e21bdbb8fa445be8fa0064199e13.

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

Marco Pivetta I wonder whether we should introduce MySqlPlatform567 to fix this which adds this behaviour. We could also fix this is MySqlPlatform directly but I don't know if this impacts performance for older versions of MySQL that don't require this behaviour.

Comment by Timothée Martin [ 09/Jan/14 ]

I encounter the same issue with doctrine/dbal 2.4.2 (commit fec965d330c958e175c39e61c3f6751955af32d0).

Have you any idea of when this bug will be fixed? Or may be can you guide me on how to fix it and I could make a PR on doctrine/dbal.

Thanks.

Comment by Steve Müller [ 09/Jan/14 ]

Cliff Odijk , Timothée Martin I will work on this issue as soon as I have time. Expect a fix for this in the upcoming weeks. Thank you for your patience.

Comment by Cliff Odijk [ 28/Jan/14 ]

The same error occurs with MariaDB version 10.0.7

  • InnoDB version 5.6.10
  • doctrine/orm version v2.4.1
  • doctrine/dbal version v2.4.2
Comment by Steve Müller [ 18/Mar/14 ]

I already started work on this but didn't have time to finish it, yet. I will try to find some time for this this evening.





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

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

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


 Description   

php app/console doctrine:migration:diff

generates redundant sql queries for postgres

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

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

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


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

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

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

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





[DBAL-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: 3
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-1046] Broken link Created: 12/Nov/14  Updated: 02/Dec/14

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

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


 Description   

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

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

Thanks



 Comments   
Comment by Steve Müller [ 02/Dec/14 ]

ted bohus for now please use this link: https://github.com/doctrine/dbal/archive/v2.3.5.zip
We are having a look into the issue.





Generated at Mon Dec 22 15:44:53 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.