[DBAL-950] [GH-637] Backport #625 Created: 22/Jul/14  Updated: 22/Jul/14

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

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


 Description   

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

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

Message:






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

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

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


 Description   

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

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

Message:

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

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



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

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





[DBAL-949] [GH-636] Update SQLSrvStatement.php Created: 22/Jul/14  Updated: 22/Jul/14

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

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


 Description   

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

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

Message:

I would like to extends functionnality of the driver.

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

I m using DBAL in Symfony 2.

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






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

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

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


 Description   

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

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

Message:

Hi,

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

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

Rgds,
Simon



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

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

Comment by Marco Pivetta [ 22/Jul/14 ]

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





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

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

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


 Description   

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

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

Message:

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

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

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

I think that this implementation checks all the boxes:

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

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

What do you think?






[DBAL-927] [GH-622] improved sqlserver 'doModifyLimitQuery' select-from pattern Created: 23/Jun/14  Updated: 21/Jul/14  Resolved: 21/Jul/14

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

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

Issue Links:
Reference
is referenced by DBAL-940 ORDER BY with LIMIT in SQL Server doe... Open

 Description   

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

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

Message:

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

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

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



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

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





[DBAL-946] Array type with non ascii chars Created: 21/Jul/14  Updated: 21/Jul/14  Resolved: 21/Jul/14

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

Type: Bug Priority: Major
Reporter: Саша Стаменковић Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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



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

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

Comment by Marco Pivetta [ 21/Jul/14 ]

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

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





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

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

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

db2 v10.5 centos 6.5 64



 Description   

The "alter column" sql produced is always incorrect.

Example entity

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

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

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

If you then change the entity like so:

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

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

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

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

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



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

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





[DBAL-945] [GH-633] Db2altercolumnsyntaxbug Created: 20/Jul/14  Updated: 20/Jul/14

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

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


 Description   

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

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

Message:

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






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

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

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

db2 v10.5 centos 6.5



 Description   

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

Example entity

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

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

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

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

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

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

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

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

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

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

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






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

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

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

centos 6 64, db2 luw10.5



 Description   

*edited*

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

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

Example entity

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

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

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

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

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

but no column alteration is obviosuly needed.

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






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

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

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


 Description   

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

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

Message:

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

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






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

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

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


 Description   

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

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

Message:

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

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






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

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

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

SQL Server


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

 Description   

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

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

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

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

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

The last format string should be:

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


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

Possible relation with DBAL-927





[DBAL-938] [GH-630] How to handle the join operations within different databases? Created: 12/Jul/14  Updated: 12/Jul/14  Resolved: 12/Jul/14

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

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


 Description   

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

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

Message:

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

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

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

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






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

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

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


 Description   

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






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

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

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


 Description   

Here is the piece of code:

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

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

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

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

Here are two solutions:

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





[DBAL-935] [GH-629] Allow to connect without a dbname param Created: 08/Jul/14  Updated: 08/Jul/14  Resolved: 08/Jul/14

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

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


 Description   

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

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

Message:

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



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

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

Comment by Marco Pivetta [ 08/Jul/14 ]

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





[DBAL-887] [GH-588] Don't return the return values of methods that do not return anything Created: 29/Apr/14  Updated: 06/Jul/14  Resolved: 29/Apr/14

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





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

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

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


 Description   

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

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

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

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

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

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






[DBAL-934] [GH-628] bug fix for db2 v10 new column def of syscat.columns.default Created: 05/Jul/14  Updated: 05/Jul/14

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

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


 Description   

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

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

Message:

It seems like ibm changed the column type of the column named "default" in syscat.columns in db2 luw v10. Probably in db2z too, but I haven't looked.

in v9.7 it was VARCHAR(254)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_9.7.0%2F2-10-7-17&lang=en

in 10.1 its CLOB(64k)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_10.1.0%2F2-9-8-18&lang=en

This causes an sql statement to fail. In
file: doctrine/dbal/lib/Doctrine/DBAL/Platforms/DB2Platform.php
method: getListTableColumnsSQL()

We make some sql like

SELECT DISTINCT c.tabschema, c.tabname, c.colname, c.colno,
c.typename, c.default, c.nulls, c.length, c.scale,
c.identity, tc.type AS tabconsttype, k.colseq
FROM syscat.columns c
...

This causes an exception like:
[IBM][CLI Driver][DB2/LINUXX8664] SQL0134N Improper use of a string column, host variable, constant, or function "DEFAULT". SQLSTATE=42907 SQLCODE=-134

The key problem here seems to be that you can't include a CLOB column in a select distinct.

At the very least, this breaks the command line tool for orm:schema-tool:update, although it might break other stuff too that I'm not aware of.

There's probably a cleaner query we can use, but I'm not familiar with the code base and what can/can't change. I don't want to introduce a bug, so I took the safe route and just did the ugly
subquery and join that shouldn't disturb anything. It's not like we need performance here.

I added a test which compares the results of the previous query with my new one. Seems to work. The test isn't something I expect to be added to your test suite - I figure someone else will run it manually to confirm my changes and then delete the test.






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

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

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


 Description   

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

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

Message:

BIGINT should be falling back to integer for SQLite



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

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

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

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

Comment by Doctrine Bot [ 04/Jul/14 ]

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





[DBAL-662] Supporting PHP 5.5 DateTimeImmutable Created: 14/Nov/13  Updated: 02/Jul/14

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

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


 Description   

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

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

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

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



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

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

Comment by Yaroslav Nechaev [ 02/Jul/14 ]

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

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

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





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

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

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

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

 Description   

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

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

Message:

Working on PostgreSQL incorrect boolean handling when emulating prepared statements



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

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

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

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

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

I'm not breaking ORM anymore.

Comment by Doctrine Bot [ 27/Jun/14 ]

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

Comment by Marco Pivetta [ 27/Jun/14 ]

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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





[DBAL-811] [GH-527] Birko boolean conversion Created: 12/Feb/14  Updated: 30/Jun/14  Resolved: 30/Jun/14

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

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

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

 Description   

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

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

Message:

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



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

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

Comment by Marco Pivetta [ 30/Jun/14 ]

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





[DBAL-931] pgSql boolean conversion Created: 30/Jun/14  Updated: 30/Jun/14  Resolved: 30/Jun/14

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: type

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

 Description   

See DBAL-811 and DBAL-863

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



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

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





[DBAL-807] Index renaming in postgresql does not work when index relates to table inside namespace Created: 08/Feb/14  Updated: 30/Jun/14  Resolved: 30/Jun/14

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

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

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

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

If index would be renamed, generated sql is:

ALTER INDEX idx_1 RENAME TO new_index_name;

But valid sql code should be:

ALTER INDEX test.idx_1 RENAME TO new_index_name;


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

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

Comment by Artur Eshenbrener [ 22/Feb/14 ]

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

Comment by Doctrine Bot [ 22/Feb/14 ]

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

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

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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

Comment by Marco Pivetta [ 30/Jun/14 ]

Resolved in DBAL-822





[DBAL-821] [GH-532] DBAL-807 [DBAL-807] - Added failing test reproduces a problem. Created: 22/Feb/14  Updated: 30/Jun/14  Resolved: 30/Jun/14

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

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

Issue Links:
Reference
relates to DBAL-807 Index renaming in postgresql does not... Resolved
is referenced by DBAL-822 [GH-533] [DBAL-807] Respect schema wh... Resolved

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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

Comment by Marco Pivetta [ 30/Jun/14 ]

Resolved in DBAL-822





[DBAL-822] [GH-533] [DBAL-807] Respect schema when renaming indexes Created: 22/Feb/14  Updated: 30/Jun/14  Resolved: 30/Jun/14

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

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

Issue Links:
Reference
relates to DBAL-807 Index renaming in postgresql does not... Resolved
relates to DBAL-821 [GH-532] DBAL-807 [DBAL-807] - Added ... Resolved

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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

Comment by Marco Pivetta [ 30/Jun/14 ]

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





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

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

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


 Description   

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

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

Message:

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






[DBAL-864] Failure to insert FALSE into a bool column Created: 10/Apr/14  Updated: 27/Jun/14  Resolved: 23/Apr/14

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

Type: Bug Priority: Major
Reporter: Matthieu Napoli Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

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

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



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

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

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

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

Comment by Matthieu Napoli [ 10/Apr/14 ]

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

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

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

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

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

Comment by Matthieu Napoli [ 10/Apr/14 ]

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

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

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

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

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

Comment by Matthieu Napoli [ 11/Apr/14 ]

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

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

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

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

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

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

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

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

Comment by Matthieu Napoli [ 11/Apr/14 ]

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

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

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

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

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

The test passes with SQLite however…

Comment by Matthieu Napoli [ 11/Apr/14 ]

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

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

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

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

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

Comment by Matthieu Napoli [ 23/Apr/14 ]

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

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

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

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

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

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

Comment by Matthieu Napoli [ 23/Apr/14 ]

> Hope this helps.

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

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

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

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

Closing this issue for now.

Comment by Doctrine Bot [ 27/Jun/14 ]

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





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

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

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


 Description   

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

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

Message:

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



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

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





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

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

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

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

Message:

The documentation incorrectly stated that their use was possible.



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

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





[DBAL-778] [GH-504] Decode hex-encoded clobs/blobs when using pgsql on windows Created: 09/Jan/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

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






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

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

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


 Description   

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

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

Message:

Added ORDER BY to doModifyLimitQuery in DB2Platform.php.






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

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

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

OSX 10.8, PHP5.4, MySQL56


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

 Description   

I am using this code from documentation

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

... and I also tried

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

but I got this error:

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

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

When I provide a type to setParamter like

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

or when I changed it to a named query it works

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

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

Message:

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

DBAL-803 #Provides a test for this issue



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

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

Comment by Benjamin Eberlei [ 08/Feb/14 ]

Fixed in the docs.





[DBAL-808] [GH-525] Added flags support for mysqli::real_connect in Mysqli driver. Created: 08/Feb/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

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

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



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

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





[DBAL-827] [GH-537] Update PDOConnection.php Created: 04/Mar/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

Remove lot of if making beautifull code using call_user_func_array



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

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





[DBAL-849] [GH-554] Add support string date modifiers for SqlitePlatform Created: 26/Mar/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

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



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

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





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

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

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


 Description   

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

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



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

This issue was fixed some time ago.

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

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

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

Comment by Guilherme Blanco [ 22/Apr/14 ]

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

Comment by Christophe Coevoet [ 22/Apr/14 ]

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

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

Comment by Guilherme Blanco [ 22/Apr/14 ]

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

Comment by Marco Pivetta [ 26/Jun/14 ]

Guilherme Blanco can you re-check this?





[DBAL-894] [GH-595] Add testGivenForeignKeyWithZeroLength_acceptForeignKeyThrowsException Created: 05/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

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





[DBAL-895] [GH-596] Fix type hint Created: 05/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

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





[DBAL-896] [GH-597] Some much needed cleanup in the TestUtil class Created: 05/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

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





[DBAL-898] [GH-599] Oracle DateTime sql declaration changed to DATE from TIMESTAMP Created: 07/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

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

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



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

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





[DBAL-899] Escape table name when update schema Created: 07/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Guilherme Santos Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: mysql, orm, schematool


 Description   

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

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

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

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

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

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



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

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

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

Moved to DBAL, this is unrelated to ORM.

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

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

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

Comment by Guilherme Santos [ 07/May/14 ]

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





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

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

Type: Bug Priority: Minor
Reporter: Hanov Ruslan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

php app/console doctrine:migration:diff

generates redundant sql queries for postgres

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

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

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





[DBAL-905] [GH-604] Remove some not needed FQNs Created: 13/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:



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

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





[DBAL-910] QueryBuilder fails when using alias in having with like expr Created: 21/May/14  Updated: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Webdevilopers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: GROUP_CONCAT, dql, expression, having, like, mysql
Environment:

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



 Description   

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

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

My example including variations inside comments:

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

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

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

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

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

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

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

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

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



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

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





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

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

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

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

 Description   

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



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

Doesn't look like a DBAL bug to me.

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

Comment by mikeSimonson [ 30/May/14 ]

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

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

To be exact, I'd discover the bug using doctrine migration.
I have made a little patch that you can use to test that case.
For the test to run you will need to adapt the credential found in the Doctrine\DBAL\Migrations\Tests\MigrationTestCase file (after applying my patch).
If you replace in that file pdo_mysql with mysqli the dirver correctly issue an error while the other does not.
I have the impression that the root issue is that when mysql is given a statment with 2 semicolons at the end, it throws an error but with an empty errno.
You can test that directly in mysql console.

Thanks

Comment by Marco Pivetta [ 06/Jun/14 ]

See https://bugs.php.net/bug.php?id=61613

Comment by Marco Pivetta [ 26/Jun/14 ]

Bug depends on a php-src bug





[DBAL-917] [GH-612] Update security.rst Created: 04/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

This is more readable (IMO).



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/059df427266d5f75326941dbb83b934696e49ed3





[DBAL-859] OraclePlatform: rownum should not be used directly in WHERE clausule Created: 12/Feb/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Critical
Reporter: Mariusz Jaskółka Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None
Environment:

Oracle, All OSes.


Attachments: File OraclePlatform.php     File OraclePlatform_bugfix.php    

 Description   

At 90% of cases when we use ROWNUM in WHERE clause it will work correctly, but sometimes not. I noticed that that is why Doctrine sometimes works incorrect.
Source:
http://www.oracle.com/technetwork/issue-archive/2006/06-sep/o56asktom-086197.html

Quote:
"That is why a query in the following form is almost certainly an error:

select *
from emp
where ROWNUM <= 5
order by sal desc;
"

I prepared modified OraclePlatform.php with solution (attachment) - rownum is being compared after all operations.



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

Mariusz Jaskółka can you please provide an example where the current implementation fails? We have functional tests LIMIT queries in DBAL but they run fine on Oracle. I need more information to be able to reproduce this problem.

Comment by Marco Pivetta [ 26/Jun/14 ]

This issue is missing a valid test case - marking as incomplete.





[DBAL-866] Foreign Key Constraints does not work with Doctrine/Symfony and SQLite Created: 12/Apr/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Christian Stoller Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 1
Labels: None
Environment:

PHP 5.5.9, SQLite3 module version 0.7-dev, SQLite Library 3.8.3.1



 Description   

I have posted a question on stackoverflow already to get help on this issue, but nobody could give me a sufficient answer. See here.

#370 says that support for foreign keys support for SQLite has been implemented. But in my case it does not work. I have defined two entities:

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Category:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    oneToMany:
        ministries:
            targetEntity: Ministry
            cascade: [persist]
            mappedBy: category

And

Unable to find source-code formatter for language: yaml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
Ministry:
    type: entity
    id:
        id:
            type: integer
            id: true
            generator:
                strategy: AUTO
    manyToOne:
        category:
            targetEntity: Category
            inversedBy: ministries
            joinColumn:
                name: category_id
                nullable: false
                onDelete: CASCADE

But when I delete a category, the ministry entities do not get deleted, although the constraint should cascade. What am I missing?

Do I have to configure anything to get that working or is it a bug?



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

While some FK functionalities are supported by the DBAL, I reverted the feature in https://github.com/doctrine/dbal/commit/7282289fee625a24c26c1fccc0474e8ca583470f since it was too clunky, so the ORM doesn't recognize the platform as a platform that supports FKs.





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

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

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


 Description   

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

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

Message:

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






[DBAL-794] [GH-517] Fix method signature in Doctrine\DBAL\Driver\Connection Created: 19/Jan/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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

Issue Links:
Duplicate
is duplicated by DBAL-799 [GH-521] Fix Connection Interface Resolved

 Description   

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

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

Message:

The method ``prepare`` must have an optional driverOptions parameter to be compatible with class which implement the interface Doctrine\DBAL\Driver\Connection.

To avoid this problem:

HipHop Fatal error: Declaration of Doctrine\DBAL\Driver\PDOConnection::prepare() must be compatible with that of Doctrine\DBAL\Driver\Connection::prepare() in /home/travis/build/symfony/symfony/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 30



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

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

Comment by Marco Pivetta [ 26/Jun/14 ]

The API was actually fixed by the HHVM folks, so we don't need the PR anymore.





[DBAL-777] [GH-503] Decode hex-encoded clobs/blobs when using pgsql on windows Created: 09/Jan/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

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



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

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

Comment by Jordi Boggiano [ 09/Jan/14 ]

This was reopened now

Comment by Doctrine Bot [ 26/Jun/14 ]

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

Comment by Marco Pivetta [ 26/Jun/14 ]

The bug is caused by an external library, and we shouldn't attempt to hotfix it.





[DBAL-921] [GH-616] Always store dates in UTC Created: 11/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

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


 Description   

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

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

Message:

This PQ will make sure that the dates saved in the database (without indication of timezone) is always stored in the UTC timezone.

I was doing development on my machine in Sweden when I noticed that when I created a `DateTime`, stored it in the db and then retrieved it again, the time was off by two hours. This is because a created the `DateTime` object with the UTC timezone. Doctrine then saved it straight to the database (by using `$date->format(...)`) and thus the information about which timezone it was in was lost. When doctrine then fetched the value, it used `DateTime::createFromFormat(...)` to create a `DateTime` for me. The problem is that since the timezone wasn't saved anywhere, it assumed that it was a Swedish date, and thus it removed two hours.

I believe that the correct way of doing it is to store the dates in the db as UTC. Then it will always work no matter what the default timezone is, even if I later decide to change it.

`date_default_timezone_set('UTC')` is not the answer. If I use it, I need to make sure that every `DateTime` that I pass to doctrine always has the timezone set to `UTC`. Since the `DateTime` can come from any number of sources (e.g. third party library) it could easily introduce hard to detect bugs. It will also output every date in the UTC timezone which may not be what I want if I'm developing a localised site (e.g. small page for a local Swedish business).



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

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





[DBAL-642] Generated IDs are not guaranteed to be unique over the table's lifetime in SQLite Created: 27/Oct/13  Updated: 25/Jun/14

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

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


 Description   

In

http://docs.doctrine-project.org/en/2.0.x/reference/basic-mapping.html#identifier-generation-strategies

it says that MySQL and SQLite use AUTO_INCREMENT by default. The generated SQL for creating an ID field with GENERATOR_TYPE_AUTO looks like this (abbreviated
for readability):

CREATE_TABLE_TEST (id INTEGER DEFAULT 0 NOT NULL, PRIMARY KEY(id))

http://www.sqlite.org/faq.html#q1 states:

If you declare a column of a table to be INTEGER PRIMARY KEY, then whenever you insert a NULL into that column of the table, the NULL is automatically converted into an integer which is one greater than the largest value of that column over all other rows in the table, or 1 if the table is empty. [...] Note that the integer key is one greater than the largest key that was in the table just prior to the insert. The new key will be unique over all keys currently in the table, but it might overlap with keys that have been previously deleted from the table.

So in other words, if you remove an entity and then create a new one, the new one will have the same id as the previously deleted one. If you do both operations on the same entitymanager, id references (in proxies f.x.) will suddenly get confused and point to something else (at least that's my current theory..)

The point is: SQLite doesn't act like MySQL as the documentation implies, and IMHO SQLite's current behaviour makes it useless for more complex scenarios. I've found some reference to this problem here:

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

Unfortunately, it doesn't mention any solution. The problem is that you can't override the columnDefinition, because it would have to be "INTEGER PRIMARY KEY AUTOINCREMENT", but then, you get an exception, because the Platform appends ", PRIMARY KEY(id)", so it's defined twice



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

As far as I understand there is a conflict in SQLite between having an autoincrement primary key and having a composite primary because you can only choose either way. The PR you referenced removed the autoincrement behaviour in favour of having the opportunity to define composite primary keys. So what would you expect to be the solution here?

Comment by flack [ 25/Nov/13 ]

Well, from a user's point of view, it would be nice if the SQLite Platform implementation would make full use of the possibilities of SQLite. That is to say: If someone uses composite primary, they get the behaviour Doctrine has right now, and those that use the simple case (which is recommended all over the documentation), get the behaviour previous to the pull request, i.e. autoincrement that works like in MySQL (which the documentation implies). As far as I understood the discussion in the pull request, the author was looking for a solution to implement this, but then the PR was merged before the issue was solved.

Comment by flack [ 25/Nov/13 ]

I guess what is bothering me is that the current behaviour breaks assumptions that I think many applications using Doctrine make. At least I know that in my own code, I never planned for the possibility of a database primary key being re-used for a different object, especially not during the same request. And like I wrote above, I suspect that Doctrine itself is not totally prepared for that situation either (also mentioned here: https://github.com/doctrine/dbal/pull/66#discussion_r173623). So IMHO the IDENTIY generator strategy for SQLite seems broken, or at least is behaving unexpectedly. The documentation says

AUTO (default): Tells Doctrine to pick the strategy that is preferred by the used database platform. The preferred strategies are IDENTITY for MySQL, SQLite and MsSQL and SEQUENCE for Oracle and PostgreSQL. This strategy provides full portability.

I don't really see how the current behaviour can be said to provide full portability (at least with MySQL, which supposedly uses the same preferred strategy)

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

Yeah I get your point. But it's always hard and error prone to work around the vendors lack of common features. A possibility COULD be to implement a trigger in columns declared as autoincrement which simulates the behaviour of an auotincrement column on inserts. Oracle uses a similar workaround with a trigger and a sequence to simulate autoincrement columns. But this is just an idea and has to evaluated for usability first.

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

Yes that's true. The documentation is misleading here. I guess that it was written before the issue came up and then was not updated. Unfortunately SQLite does not support native sequences which would make life a lot easier. But I will keep that in mind and investigate a solution for this.

Comment by Benjamin Eberlei [ 13/Dec/13 ]

I think there is no fix for this, this is just how SQLite works, and we cannot really keep the last ids somewhere. IMHO its a documentation issue.

Comment by flack [ 13/Dec/13 ]

Well, you cannot fix it for cases with multiple id columns (but the Doctrine documentation already suggests that they should be avoided where possible), but for single integer columns (which is the normal case, as suggested by documentation), SQLite provides all the necessary functionality, as long as you create the column with INTEGER PRIMARY KEY AUTOINCREMENT. So IMHO the best solution would be if support for this could be implemented somehow in the SQL Platform driver.

Comment by flack [ 14/Dec/13 ]

Case in point: I implemented exactly this in a Doctrine adapter I'm working on:

https://github.com/flack/midgard-portable/blob/master/src/midgard/portable/storage/subscriber.php#L136

Granted, this is a very ugly workaround that only works because I know all my ID columns are actually called 'id' (and will never change), but I'm fairly sure that a more general solution could be built with reasonable effort.

Comment by Benjamin Eberlei [ 01/Jan/14 ]

flack We removed the Sqlite AUTOINCREMENT for some weird reason. I am inclined to add this again, however I need to find out what the reasons for removing this have been.

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

Benjamin Eberlei I checked that lately and I came to the same conclusion. The reason why it was removed is to support composite primary keys which was not possible before somehow. We could add autoincrement if only a single column integer primary key is given I think...

Comment by flack [ 25/Jun/14 ]

Just noticed that the link I posted above is broken now. Here's a stable one:

https://github.com/flack/midgard-portable/blob/04d473356d804c7f64e940ef82dd1538c39fccdd/src/storage/subscriber.php#L170

The workaround is a bit less project-specific now, and might serve as the basis for a real solution I guess (basically, only checks for column type and composite keys would need to be added)





[DBAL-928] [GH-623] Prevent Connection from maintaining a second reference to an injected PDO object. Created: 25/Jun/14  Updated: 25/Jun/14  Resolved: 25/Jun/14

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

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


 Description   

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

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

Message:

Previously, if a developer explicitly closed the Connection, only the _conn reference was destroyed, but the _params['pdo'] reference remained and kept the PDO connection alive. By unsetting the _params reference, we maintain only the _conn reference, exactly as if the PDO connection is generated internally.



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

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





[DBAL-926] [GH-621] Use PSR-4 for Doctrine DBAL Created: 20/Jun/14  Updated: 20/Jun/14  Resolved: 20/Jun/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

symfony/symfony#11189 for Doctrine DBAL



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

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





[DBAL-925] [GH-620] Correct SQL Anywhere driver default port to 2638 Created: 19/Jun/14  Updated: 19/Jun/14  Resolved: 19/Jun/14

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

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


 Description   

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

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

Message:

It looks like this was a simple typo.

References:
SQLA16 - http://dcx.sybase.com/index.html#sa160/en/dbadmin/serverport-network-conparm.html
SQLA12 - http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.11.0.1/dbadmin_en11/serverport-network-conparm.html

It probably wasn't noticed immediately due to the fact SQL Anywhere drivers cache database server address information in a file on disk (sasrv.ini). Once the cache is populated with the database name, it's possible to connect successfully even if the port you were specifying in your code was incorrect (like 2683).

http://dcx.sybase.com/1201/en/dbadmin/servernamecaching.html



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

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

Comment by Marco Pivetta [ 19/Jun/14 ]

Merged: https://github.com/doctrine/dbal/commit/247bd099b8f74eed3d7bdb42a5e0bb1af1925dce





[DBAL-924] [GH-619] fix all sqlite integer types Created: 16/Jun/14  Updated: 16/Jun/14

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

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


 Description   

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

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

Message:

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






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

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

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


 Description   

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

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

Message:

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

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

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






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

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

Type: Improvement Priority: Minor
Reporter: Matteo Beccati Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.6+, pdo_pgsql



 Description   

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

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

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

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






[DBAL-915] emulate named parameters for statement with the mysqli driver Created: 30/May/14  Updated: 05/Jun/14  Resolved: 03/Jun/14

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

Type: Improvement Priority: Major
Reporter: mikeSimonson Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-918 [GH-614] Correcting the doc because m... Open

 Description   

Hi,

Would it be reasonable to try to emulate named parameters in the mysqli driver?

The goal is that we still could use named parameters and that the DBAL mysqli driver would automatically replace the named parameters by questions marks and pass the parameters in the right order according to those question marks ?

The main problem I see is that we might replace stuff in the query that shouldn't be replaced. And in that case it might be good to have a way to disable that behavior (don't know if it's easy to do in the DBAL code base).
On the other hand we could also ask the user to change it's parameter name even if it's not ideal it's also probably the fastest fix. The corner problem here is that I don't know the rules that are applied by pdo_mysql to replace the named parameters in a prepared statement, if there are any.

Is it a good or bad idea and why ?
Thanks



 Comments   
Comment by mikeSimonson [ 31/May/14 ]

Btw I just realised that in the mysqli doctrine driver documentation it's indicated as supported. So maybe I should just add it.

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

mikeSimonson I'm not quite sure what your issue is here as the DBAL Connection already converts named parameters into positional parameters under the hood. See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php
Or am I getting you wrong here?

Comment by mikeSimonson [ 02/Jun/14 ]

Is it possible that I did something the wrong way so that, that emulation is not used.
My query is only a select with " WHERE id = :id ". That crash telling me that there is an error in my sql syntax and when I replace it with " WHERE id = ? " it works perfectly.
That is with the mysqli driver on symfony2.4.

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

Can you provide a code snippet of how you executed the query? Did you use the DBAL\Connection object? AFAIK you cannot use the mysqli driver connection directly because the parameter conversion from named to positional is done through DBAL\Connection

Comment by mikeSimonson [ 02/Jun/14 ]

I am in a Repository (entity) and I am using

 $this->getEntityManager()
            ->getConnection()
            ->prepare("SELECT * FROM person WHERE id =:id");

/** The query is trimmed for readability **/

Comment by mikeSimonson [ 02/Jun/14 ]

Just to make sure I tested with that exact same query.

If I use pdo_mysql the query runs fines and then I change the driver in the dbal config file to mysqli and it tell me that my sql is wrong. I change the sql to use question mark and it's fine again.

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

DBAL\Connection::prepare() does not convert named into positional parameters. It works with pdo_mysql because pdo_mysql supports named parameters natively. You have to use one of the other (direct) query methods like DBAL\Connection::fetch*() or DBAL\Connection::executeQuery().

Comment by mikeSimonson [ 02/Jun/14 ]

So, what you say is that it's not possible to have prepared statement with named parameter and mysqli.
And I want to hook that sqlParserUtils method to be able to use the named parameters with mysqli statement too.

Does that make sense ?

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

Sure you can have a prepared statement and named parameters with mysqli. It's just that DBAL\Connection::prepare() gives you a "raw" prepared statement, whereas executeQuery() gives you a prepared statement with a preprocessed SQL (named to positional conversion, array parameter expansion etc.). I think the fact that DBAL\Connection::prepare() does not convert the parameters for you automatically is that it does not take any parameters (as you have to bind them manually afterwards) which is necessary for the SQLParserUtils to rewrite the SQL appropriately. So either use one of the fetch*() methods with named parameters to retrieve a result directly or use exceuteQuery() to get a prepared statement (with converted named parameters). If you however really want to use prepare() (for whatever reason) then you will have to utilize the SQLParserUtils manually in order to get your named parameters converted into positionals before executing the query.
Hope this helps.

Comment by mikeSimonson [ 02/Jun/14 ]

Ok.

So it's just a misunderstanding of my part that to have a prepared statement you need to use the prepare method.
In that case I will just use the executeQuery or query.

Thanks for you help.

What are the differences then between all those methods then.
Also when I look in the documentation it quite unclear I think.
If you go in the mysqli driver documentation it states that the driver support the prepared statement with a named parameter.
At least it's that way that I understand it.

When I will have understand the difference between all those method I will try to explicit it in the documentation.

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

Please have a look at the DBAL documentation to understand the differences between the available query methods in Doctrine\DBAL\Connection:

http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/data-retrieval-and-manipulation.html#api

The reason why the mysqli driver API documentation states, it supports also named parameters is because the documentation is inherited from the Doctrine\DBAL\Driver\Statement interface which Doctrine\DBAL\Driver\Mysqli\MysqliStatement implements. Basically the interface is adopted from PHP's \PDOStatement and therefore a bit misleading here concerning named parameters, that's true. Sorry for the confusion.

Comment by mikeSimonson [ 03/Jun/14 ]

TLDR;
It seems that executeQuery fails to treat the param as int when it's told too and that a named parameter is used.

Closer look.

I did change the prepare call into a call to executeQuery.
It now looks like that:

$stmt = $this->getEntityManager()
            ->getConnection()
            ->executeQuery("
                      SELECT ..... FROM ..... lots of join 
                      WHERE id = :id
                     ", array('id' => 10000107),
               array(\PDO::PARAM_INT)
);

That query fails miserably (aka mysql use 100% of the processor for what seems like forever and I kill it).
I realized that the query passed to phpmyadmin runs smootly if I write the were like this

                WHERE id = 10000107

but fails also if the query is passed with the id quoted

                WHERE id = '10000107'
                WHERE id = "10000107"

I think that a part of the problem is that when I do executeQuery with a named parameter and a paramType as \PDO::PARAM_INT, the parameter is not passed as an int but as a string.
The funny one is that you can use any quoting you want in your param if you don't use named parameters, and all those run smoothly :

$stmt = $this->getEntityManager()
            ->getConnection()
            ->executeQuery("
                      SELECT ..... FROM ..... lots of join 
                      WHERE id = ?
                     ", array('1' => 10000107),
               array(\PDO::PARAM_INT)
);
, array('1' => '10000107'),
               array(\PDO::PARAM_INT)
);
, array('1' => "10000107"),
               array(\PDO::PARAM_INT)
);

If anyone see any reason why that fails I am more than interested.
Besides the fact that mysql probably shouldn't have any problem with the way the is passed ( as string or int), I also think that executeQuery fails to treat the param as int when it's told too and that a named parameter is used.

What do you think ?

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

Not sure if that fixes the issue but you have to pass a map of types as third argument like

$query = 'SELECT foo FROM bar WHERE id = :id';
$stmt = $this->getEntityManager()
    ->getConnection()
    ->executeQuery($query, array('id' => 10000107), array('id' => \PDO::PARAM_INT));

Otherwise the parameters will be bound without a specific type, therefore seemingly mapping to string by default.
See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Connection.php#L1477-L1483

Edit: Sorry fixed the example.

Comment by mikeSimonson [ 03/Jun/14 ]

Aarg just saw your email.

Thanks it works perfectly now.

Comment by mikeSimonson [ 03/Jun/14 ]

Should I just add a new example in the documentation with a named parameter (bellow the one with a positional param) in http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/data-retrieval-and-manipulation.html#executequery ?

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

Yeah might be a good idea to add the corresesponding examples with named parameters for executeQuery(), fetchAll(), fetchArray(), fetchColumn(), fetchAssoc(). Go ahead, open a PR and I'll merge then. Thanks.





[DBAL-332] Memory option for Sqlite driver does nothing Created: 29/Aug/12  Updated: 04/Jun/14  Resolved: 17/Sep/12

Status: Closed
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.2.2, 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Damien ALEXANDRE Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

PHP Version 5.3.10
SQLite Library 3.7.9
Doctrine 2.3.x-dev
Dbal 2.3.x-dev
Symfony 2.1 RC2



 Description   

I'm trying to configure a "memory" sqlite database, as described here: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#pdo-sqlite

So here is my configuration (config_test.yml) :

Unable to find source-code formatter for language: yml. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
 
doctrine:
    dbal:
        driver:    pdo_sqlite
        memory:    true
        user:      db_user
        password:  db_pwd
        charset:   UTF8

I'm then running

./app/console doctrine:database:create --env=test

and the result is a "myBdName" db file (the filename contains the quote!!) in my root folder.

I don't understand why the file http://www.doctrine-project.org/api/dbal/2.3/source-class-Doctrine.DBAL.Schema.SqliteSchemaManager.html#46 is creating a path option with my DB name, if I comment the line 57, everything seems fine (no more file created).

I have seen some memory related options in the Doctrine test suite so maybe I'm doing it wrong, and in that case that's a documentation issue I can work on.

Thx,
Damien



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

You cannot create an in memory database using Symfonys database:create. The in memory database will be closed when the request ends. So its completly useless this way. You have to recreate it in every request that you want to use it. It is just good for one request.

Comment by Damien ALEXANDRE [ 06/Sep/12 ]

My example with "app/console" is misleading,
what I want to do is building a memory SQLite database on the fly and run some code right after it (in a phpunit test).

The issue here is that there is an option documented (first link) that doesn't work / is not implemented (second link). And a physic file is generated, it should not.

As your answer seems to be based on the mistaken impression that I wanted to use volatile database in a persistent way, I'm reopening this issue.

Thanks for your time.
Damien.

Comment by Benjamin Eberlei [ 07/Sep/12 ]

Try removing the user/password keys. memory database connection works for me, this seems to be a configuration issue.

If you want to create an in memory db for testing then you have to create the schema with SchemaTool inside the phpunit tests.

Comment by Benjamin Eberlei [ 17/Sep/12 ]

No feedback on potential fix, this issue is either misconfiguration or wrong use of the API. I couldn't reproduce this and it works for me (TM).

Comment by Iain Potter [ 04/Jun/14 ]

Hi guys, this does not work for me either. Same use case.

Config:

driver: pdo_sqlite
memory: true

Comment by Iain Potter [ 04/Jun/14 ]

Apologies for resurrecting an old issue but a google search brought me here.





[DBAL-916] Some alter table statements do not respect @Table name value Created: 30/May/14  Updated: 04/Jun/14

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

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

MacOS



 Description   

I have specified the table name for each class generating a table. I find that some table names are respected during doctrine update upon the database, and some are not.

Specifically it seems that simpler entities, one's annotated with entity/table become lower case, while more complicated ones (inheritance map) respect the given table name.



 Comments   
Comment by Julia Smith [ 03/Jun/14 ]

On further inspection, this does not appear to be a bug with Doctrine. A simple dump of the update statements generated shows no table name change, but:

ALTER TABLE Comment DROP FOREIGN KEY FK_5BC96BF03DBEAF48;
DROP INDEX IDX_5BC96BF03DBEAF48 ON Comment;
ALTER TABLE Comment CHANGE replyto_id replytox_id INT DEFAULT NULL;
ALTER TABLE Comment ADD CONSTRAINT FK_5BC96BF0484A4D29 FOREIGN KEY (replytox_id) REFERENCES Comment (id);
CREATE INDEX IDX_5BC96BF0484A4D29 ON Comment (replytox_id);

Somehow causes mysql to change the case of the table on MacOS.

weird.

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

Julia Smith can you please provide more details concerning your actual problem? I'm not sure I understand what the problem is here. I can't see how the SQL you pointed out changes a table's name in any way so I don't understand how that could change the table name's case.
Concerning identifier casing in general I would suggest you to read the following from the MySQL documentation:
http://dev.mysql.com/doc/refman/5.5/en/identifier-case-sensitivity.html

And a pretty good explanation of the problem with identifiers and case accross operating systems and database vendors:
http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html#.U47DV3IZWlM

If the casing of identifiers (table names, column names etc.) in your schema is important for you, you will either have to quote those in your mapping explicitly or use a custom quoting strategy. Please refer to the documentation for further details:
http://docs.doctrine-project.org/en/latest/reference/basic-mapping.html#quoting-reserved-words

Hope that helps.





[DBAL-911] Property access not yet allowed in path/to/MysqliConnection.php Created: 21/May/14  Updated: 22/May/14  Resolved: 22/May/14

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

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


 Description   

Updated doctrine/dbal from 0a7df7c58aeab4d1cef55a78e5ca50299a12a62b to 2.5.0-beta3 and received the following warning:

PHP Warning:  Doctrine\DBAL\Driver\Mysqli\MysqliConnection::__construct(): Property access is not allowed yet in /path/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/MysqliConnection.php on line 60


 Comments   
Comment by Till [ 22/May/14 ]

This duplicates DBAL-912 and can be closed.





[DBAL-912] [GH-611] Fix: property access is not allowed yet Created: 21/May/14  Updated: 21/May/14  Resolved: 21/May/14

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

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


 Description   

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

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

Message:

Fixes the warning emitted by mysqli when sqlstate is not set (yet?).
http://git.php.net/?p=php-src.git;a=blob;f=ext/mysqli/mysqli_prop.c;h=2d36336372b75922bd8fbf40c5c9054a5230c8a0;hb=HEAD#l36

Warning masks actual connection error.

Related:
http://www.doctrine-project.org/jira/browse/DBAL-911



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

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

Comment by Benjamin Eberlei [ 21/May/14 ]

Merged





[DBAL-524] [GH-322] DBAL-522 Created: 20/May/13  Updated: 21/May/14  Resolved: 21/May/13

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

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


 Description   

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

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

Message:

Hotfix for DBAL-522(http://www.doctrine-project.org/jira/browse/DBAL-522)

Demonstrates that NULL parameters are handled incorrectly by `Doctrine\DBAL\SqlParserUtils` as of 2.3.4.

Basically, following usage always throws an exception:

$conn->executeQuery(
    'INSERT INTO FOO (foo, bar) values (:foo, :bar)', 
    array('foo' => 1, 'bar' => null)
);


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

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

Comment by Doctrine Bot [ 21/May/14 ]

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





[DBAL-515] [GH-315] Shard description requires an 'id' not 'name' Created: 14/May/13  Updated: 19/May/14  Resolved: 14/May/13

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 14/May/13 ]

merged

Comment by Doctrine Bot [ 19/May/14 ]

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





[DBAL-514] [GH-314] Remove unnecessary code from Connection::insert Created: 13/May/13  Updated: 19/May/14  Resolved: 14/May/13

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

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


 Description   

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

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

Message:

This is a tiny optimization in the <code>Connection::insert</code> method that remove an unnecessary <code>foreach</code> loop an some unneeded variable assignments.
If this is not desired, just close this PR



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

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

Comment by Marco Pivetta [ 14/May/13 ]

merged

Comment by Doctrine Bot [ 19/May/14 ]

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





[DBAL-501] [GH-309] Parameter parsing fixes Created: 21/Apr/13  Updated: 19/May/14  Resolved: 09/May/13

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

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


 Description   

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

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

Message:

Fix for #301 has been reverted to address http://www.doctrine-project.org/jira/browse/DBAL-496. This fix addresses both issues in a consistent manner and ads a few more tests.



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

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

Comment by Doctrine Bot [ 19/May/14 ]

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





[DBAL-840] [GH-546] [DBAL-474] Fix filtering sequence names on PostgreSQL Created: 19/Mar/14  Updated: 16/May/14  Resolved: 16/May/14

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

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


 Description   

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

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

Message:

The PostgreSQL schema manager has to filter sequence names before actually creating `Sequence` objects to avoid errors on accessing sequence database objects where the user has not enough privileges for.
The reason for this is that retrieving sequence attributes other than the sequence name requires accessing the particular sequence database object directly which requires the connected user to have enough privileges. This might not always be the case if for example a particular user can only access certain schemas but not others.
This patch might not be the best solution but a good compromise IMO. Changing the `AbstractSchemaManager` to filter sequence names before creating `Sequence` objects might affect other platforms and could also perhaps break BC. Furthermore this issue is completely PostgreSQL specific as it is the only currently supported platform not having a sequence's attributes stored directly in the system catalogs (AFAIK).



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

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

Comment by Marco Pivetta [ 16/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/6252da0cf1ed04cc790af533f0841bf5c01de44e





[DBAL-474] SchemaManager / Connection on PostgreSQL platform does not respect filterExpression for sequences Created: 27/Mar/13  Updated: 16/May/14

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

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: postgresql, schematool
Environment:

Windows & Linux



 Description   

Dear Symfony team,

the filterExpression on AbstractSchemaManager seems not to work for sequences.

This only happens under postgres.

It seems the way the sequences are handled are the culprit: It tries to get min_value etc of sequences without matching sequence names to the filter expression in advance.

If for example access to the sequences is denied, (Different schema without permissions for the current entity manager), any higher-level ORM operations like generating migration versions fail.

--------------------- UPDATE

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.



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

Can you paste an exception trace? I see that filtering is applied to sequences, but your description seems to indicate this happens due to an SQL query much earlier?

Comment by jos de witte [ 24/Apr/13 ]

Dear Benjamin,

the context is when using migrations. Positive regexp expressions do not limit the migration to a single schema. eg ^schemaname.$
Instead, all sequences on the current database are returned.
When trying to limit a migration to a single schema consecutively this doesn't work.
We are using a per-schema connection, so this results in a lot of hassle for us.

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

jos de witte I think your issue got fixed in commit: https://github.com/doctrine/dbal/commit/8beb732fe9d5cd40a0d677f250d2be325482744f
This patch was first introduced in 2.3. Can you please confirm that this is fixed? Otherwise can you please provide a concrete example so that we can reproduce you issue?

Comment by Arnout Standaert [ 29/Jan/14 ]

I believe we are bumping into the same issue. Our webapp uses Migrations, but for our webapp we are limited to a certain schema within a bigger PostgreSQL database. We only have permissions on our own schema and public.
Now, listSequences in AbstractSchemaManager does filter the asset names correctly with the mentioned fix.

But the problem is with the step before, _getPortableSequencesList (see line 135 of AbstractSchemaManager):

        return $this->filterAssetNames($this->_getPortableSequencesList($sequences));

This function goes out and does a _getPortableSequenceDefinition on every sequence in the unfiltered list. For every sequence, the _getPortableSequenceDefinition in PostgreSqlSchemaManager performs a SELECT:

        $data = $this->_conn->fetchAll('SELECT min_value, increment_by FROM ' . $this->_platform->quoteIdentifier($sequenceName));

Now, our user role in the database doesn't have SELECT permissions on these sequences in other schemas, so the migration fails with a privilege error.

There should be some kind of filtering on the sequence list BEFORE the SELECT statement in the _getPortableSequenceDefinition function are performed, no?

Comment by Arnout Standaert [ 30/Jan/14 ]

I currently have a workaround running locally, which filters the sequences list before creating the PortableSequence's. This is probably hackish and a poor workaround, just posting here as a temporary solution and further illustration of the problem.

Altered line 135 in AbstractSchemaManager:

        return $this->_getPortableSequencesList($this->filterSequenceNames($sequences));

I added function filterSequenceNames() in AbstractSchemaManager for appropriate sequence filtering:

    /**
     * Filters sequence names if they are configured to return only a subset of all
     * the found elements.
     *5
     * @param array $sequenceNames
     *
     * @return array
     */
    protected function filterSequenceNames($sequenceNames)
    {
        $filterExpr = $this->getFilterSchemaAssetsExpression();
        if ( ! $filterExpr) {
            return $sequenceNames;
        }
        
        return array_values ( array_filter($sequences, function ($sequenceName) use ($filterExpr) {
                $sequenceName = $sequenceName["schemaname"].".".$sequenceName["relname"];
                return preg_match($filterExpr, $sequenceName);
            })
        );

    }

After these modifications, doctrine:migrations:migrate operations complete succesfully, even with our limited-permission database account.

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

Arnout Standaert Your fix looks promising and reasonable. Can you create a PR on the DBAL repo for that?

Comment by Viktor Sidochenko [ 15/Mar/14 ]

Why this fix is not in master?

Comment by Steve Müller [ 15/Mar/14 ]

Viktor Sidochenko because nobody has fixed it yet Feel free to provide a patch on GitHub.

Comment by Arnout Standaert [ 17/Mar/14 ]

I haven't gotten around to doing the PR on GitHub yet, I'm not yet too familiar with that.
I'll try to find some time for this the coming days.

Comment by Viktor Sidochenko [ 17/Mar/14 ]

Will be good. I`m not professional developer to make patches to upstream. So just voted for this issue.

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

Patch supplied in PR: https://github.com/doctrine/dbal/pull/546
jos de witte, Arnout Standaert, Viktor Sidochenko can you please test if the supplied PR fixes the problem?

Comment by Doctrine Bot [ 16/May/14 ]

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





[DBAL-855] [GH-560] Fix DateTimeTz type compatibility on SQL Anywhere versions < 12 Created: 31/Mar/14  Updated: 16/May/14  Resolved: 16/May/14

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

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


 Description   

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

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

Message:

SQL Anywhere versions < 12 do not support a native date time with timezone type. Therefore the fallback strategy is to use the normal date time type. However the format of the date time tz type declaration has to correspond to the normal date time type declaration, too then.

`getDateTimeTzTypeDeclarationSQL()` -> `getDateTimeTypeDeclarationSQL()`
`getDateTimeTzFormatString()` -> `getDateTimeFormatString()`

I thought about changing that in the `AbstractPlatform` but I am not sure if that might break assumptions in userland code and therefore BC. So I left the implementation SQL Anywhere specific.



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

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

Comment by Marco Pivetta [ 16/May/14 ]

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





[DBAL-856] [GH-561] Fix FOR UPDATE SQL on SQL Anywhere Created: 31/Mar/14  Updated: 16/May/14  Resolved: 16/May/14

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

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


 Description   

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

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

Message:

It looks like there was a misunderstanding on SQL Anywhere with the `FOR UPDATE` SQL as this is actually a statement used in prepared statements and does not work the ANSI way in ORM. So I removed it in favour of the table lock hint implementation which works out quite well and makes the `getForUpdateSQL()` rather useless anyways. SQL Server does it like this, too btw and both dialects are pretty similar because SQL Anywhere once drived from it.



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

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

Comment by Marco Pivetta [ 16/May/14 ]

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





[DBAL-877] [GH-575] [DBAL-801] Add date arithmetic interval methods for seconds, minutes, weeks, quarters and years Created: 24/Apr/14  Updated: 16/May/14  Resolved: 16/May/14

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

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


 Description   

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

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

Message:

This PR adds missing methods for additional date arithmetic interval expression of seconds, minutes, weeks, quarters and years.
Additionally all platforms have been refactored to avoid a lot of code duplication through a more common protected extension point method `AbstractPlatform::getDateArithmeticIntervalExpression()`.



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

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

Comment by Marco Pivetta [ 16/May/14 ]

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





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

Status: In Progress
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None

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


 Description   

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

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



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

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

Comment by Doctrine Bot [ 16/May/14 ]

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





[DBAL-900] [GH-600] Support for Partial Indexes for PostgreSql and Sqlite Created: 07/May/14  Updated: 16/May/14

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

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

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

 Description   

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

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

Message:

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

It is unit-tests covered and documented in manual.



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

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

Comment by Doctrine Bot [ 16/May/14 ]

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





[DBAL-44] nullable is not working for all datatypes Created: 30/Aug/10  Updated: 16/May/14  Resolved: 30/Aug/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0-BETA3

Type: Bug Priority: Critical
Reporter: Daniel Freudenberger Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None

Attachments: Text File nullable.patch    
Issue Links:
Reference
is referenced by DDC-1045 Schema-tool update missbehavior: Not ... Closed

 Description   

The nullable=true annotation is ignored from at least following Types:

  • SmallIntType
  • DecimalType
  • BooleanType (not sure if nullable makes sense here)


 Comments   
Comment by Roman S. Borschel [ 30/Aug/10 ]

This looks like it has been fixed for a while already. See:

http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/SmallIntType.php
http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DecimalType.php
http://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/BooleanType.php

Comment by Daniel Freudenberger [ 30/Aug/10 ]

I'll take a look at the master next time before submitting a bug report. Anyway I think it would be better to not fix bugs without an existing ticket for the fixed bug

Comment by Daniel Freudenberger [ 30/Aug/10 ]

has already been fixed





[DBAL-720] [GH-456] [DBAL-44] Fix column default value lifecycle Created: 22/Dec/13  Updated: 16/May/14  Resolved: 22/Dec/13

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

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

Issue Links:
Reference
is referenced by DDC-1045 Schema-tool update missbehavior: Not ... Closed

 Description   

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

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

Message:

This is an approach to make the "lifecycle" of a column's default value more consistent and less error prone. It also fixes some platform implementations, especially when a column's default value has to be dropped (which requires an explicit drop clause on some vendors).
This implementation implies a default value of `null` as no default value set. All other values get evaluated as a default value.



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

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





[DBAL-897] [GH-598] Adding doctrine-dbal to composer.json and making it work Created: 06/May/14  Updated: 13/May/14  Resolved: 13/May/14

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

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


 Description   

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

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

Message:

This PR fixes doctrine-dbal bin file that was not working as expected and adds it to composer.json.
The changes I've made on ```doctrine-dbal.php``` makes it work just like doctrine ORM cli app.



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

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

Comment by Marco Pivetta [ 13/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/0df188624892ecc58751b3f7720c364dac99f998





[DBAL-908] [GH-610] Remove @param tags that add no value Created: 13/May/14  Updated: 13/May/14  Resolved: 13/May/14

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

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


 Description   

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

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

Message:

As remarked on #609



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

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

Comment by Marco Pivetta [ 13/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/5d12e3f9915c2a2d3b87abf1d18073495be85853





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

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 13/May/14 ]

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





[DBAL-907] [GH-606] Remove ref to class that does not exist Created: 13/May/14  Updated: 13/May/14  Resolved: 13/May/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 13/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/5340e9f5f512f4e54e9195d977de772555a1cc47





[DBAL-904] [GH-603] Remove duplicate suggest section in composer.json Created: 13/May/14  Updated: 13/May/14  Resolved: 13/May/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 13/May/14 ]

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





[DBAL-839] [GH-545] [DBAL-835] Quote old column name in rename column SQL Created: 19/Mar/14  Updated: 09/May/14  Resolved: 09/May/14

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

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

Issue Links:
Duplicate
duplicates DBAL-835 Old column name not quoted during col... Resolved

 Description   

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

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

Message:

Quotes old column name in `ALTER TABLE` statements if necessary when a column gets renamed.

Note: The `AbstractSQLServerPlatformTestCase::getQuotedAlterTableRenameColumnSQL()` method need adjustments as soon as PR #542 gets merged (the `ALTER TABLE` statements need to be removed).



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/9d6300fd862478f58a526fbcad0a8f630daa60aa





[DBAL-835] Old column name not quoted during column rename in MySQL Created: 12/Mar/14  Updated: 09/May/14  Resolved: 09/May/14

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

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

CentOS with Doctrine 2.3 MySQL 5.5.31


Issue Links:
Duplicate
is duplicated by DBAL-839 [GH-545] [DBAL-835] Quote old column ... Resolved

 Description   

This is a broken feature, because escaping only sometimes (behavior at least in 2.3, if it has not been fixed after that) leads to breaking things. It is possible to CREATE a column named `usage` (without any backticks in the code), but things break from that point on. If I try to change the column name to a non-reserved word later, ALTER TABLE syntax will break

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE products CHANGE usage purpose VARCHAR(256) NOT NULL':

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'usage purpose VARCHAR(256) NOT NULL' at line 1

Migrating down then again escapes the column name even if it wasn't escaped in the definition.

I found a ticket from 2012 describing that column names using reserved keywords should be escaped manually, but since migrations will lead into a dead-end with at least using `usage` as a column name, this feature is somewhat broken.



 Comments   
Comment by Steve Müller [ 12/Mar/14 ]

Arttu Manninen There have been some fixes around quoting identifiers in DDL lately. It seems there is one missing around $oldColumnName in MySqlPlatform::getAlterTableSQL().
I have moved this issue to DBAL as it is an issue there.

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

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

Comment by Doctrine Bot [ 09/May/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/9d6300fd862478f58a526fbcad0a8f630daa60aa





[DBAL-883] [GH-584] Properly instantiate var and fix spelling Created: 29/Apr/14  Updated: 09/May/14  Resolved: 09/May/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 09/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/2f34a3cf98f9370fd456dba640fdc7933f2ccf8a





[DBAL-902] [GH-602] HHVM nightly and PHP 5.6 in builds Created: 09/May/14  Updated: 09/May/14  Resolved: 09/May/14

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

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


 Description   

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

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

Message:



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

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

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

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





[DBAL-833] [GH-542] [DBAL-825] Drop default constraints before altering column type on SQL Server Created: 07/Mar/14  Updated: 08/May/14  Resolved: 08/May/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: sqlserver, sqlsrv

Issue Links:
Duplicate
duplicates DBAL-825 ALTER COLUMN on mssql is failing if d... Resolved
duplicates DBAL-826 [GH-536] [WIP] unit test for DBAL-825 Resolved

 Description   

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

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

Message:

SQL Server implements column default values as constraints and therefore requires them to be dropped before a column type change.
This PR implements the recreation of default constraints on column type alterations.
Additionally some code in `SQLServerPlatform::getAlterTableSQL()` has been refactored to avoid code duplication and unnecessary SQL generation.
Please note that due to the issue's tests the PostgreSQL platform had to be altered to fulfill the same behaviour. PostgreSQL returned some strange default value like `666:smallint` when reverse engineering a column type change with a default value of `666` from type `smallint` to `integer`. So I think this PR fixes a bug in this platform, too. Additionally I had to change the deprecated default value retrieval SQL in PostgreSQL in order to work flawlessly. See the [documentation](http://www.postgresql.org/docs/9.3/static/catalog-pg-attrdef.html) at the very end.

I would also like to note that this PR is definitely not the end of the line concerning default values and column alterations. Some weird errors were revealed on other platforms while fixing this issue. MySQL for example denies default values on BLOB/TEXT type columns, DB2 just throws non-understandable syntax errors around and Oracle seems to map decimal/numeric types without a defined scale to integer when reverse engineering (not really related to this issue but it came up while testing).

Otherwise the tests pass on all platforms.



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

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

Comment by Doctrine Bot [ 08/May/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/171a8762673ee61a89e3d6ce891cd2b475e7b5f7





[DBAL-825] ALTER COLUMN on mssql is failing if default constraint is attached Created: 03/Mar/14  Updated: 08/May/14  Resolved: 08/May/14

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

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

MSSQL


Issue Links:
Duplicate
is duplicated by DBAL-826 [GH-536] [WIP] unit test for DBAL-825 Resolved
is duplicated by DBAL-833 [GH-542] [DBAL-825] Drop default cons... Resolved

 Description   

Here is the unit test - implemented in class SchemaManagerFunctionalTestCase

 
    public function testChangeColumnsTypeWithDefault()
    {
        $table = new \Doctrine\DBAL\Schema\Table('column_change_type_test');
        $table->addColumn('id', 'integer', array('default' => 5));

        $this->_sm->createTable($table);

        $columns = $this->_sm->listTableColumns("column_change_type_test");
        $this->assertEquals(1, count($columns));
        $this->assertInstanceOf('Doctrine\DBAL\Types\IntegerType', $columns['id']->getType());

        $tableDiff = new \Doctrine\DBAL\Schema\TableDiff('column_change_type_test');
        $tableDiff->changedColumns['id'] = new \Doctrine\DBAL\Schema\ColumnDiff(
            'id', new \Doctrine\DBAL\Schema\Column(
                'id', \Doctrine\DBAL\Types\Type::getType('smallint'), array('default' => 5)
            ),
            array('type'),
            new \Doctrine\DBAL\Schema\Column(
                'id', \Doctrine\DBAL\Types\Type::getType('integer'), array('default' => '5')
            )
        );

        $this->_sm->alterTable($tableDiff);

        $columns = $this->_sm->listTableColumns("column_change_type_test");
        $this->assertEquals(1, count($columns));
        $this->assertInstanceOf('Doctrine\DBAL\Types\SmallIntType', $columns['id']->getType());
        $this->assertSame('', $columns['id']->getDefault());
    }

Causes following result

 
Exception : [Doctrine\DBAL\DBALException] An exception occurred while executing 'ALTER TABLE column_change_type_test ALTER COLUMN id SMALLINT NOT NULL':

SQLSTATE [42000, 5074]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The object 'DF_A74995E2_BF396750' is dependent on column 'id'.
SQLSTATE [42000, 4922]: [Microsoft][SQL Server Native Client 11.0][SQL Server]ALTER TABLE ALTER COLUMN id failed because one or more objects access this column.

With queries:
5. SQL: 'ALTER TABLE column_change_type_test ALTER COLUMN id SMALLINT NOT NULL' Params: 
4. SQL: 'SELECT    col.name,
                          type.name AS type,
                          col.max_length AS length,
                          ~col.is_nullable AS notnull,
                          def.definition AS [default],
                          col.scale,
                          col.precision,
                          col.is_identity AS autoincrement,
                          col.collation_name AS collation,
                          CAST(prop.value AS NVARCHAR(MAX)) AS comment -- CAST avoids driver error for sql_variant type
                FROM      sys.columns AS col
                JOIN      sys.types AS type
                ON        col.user_type_id = type.user_type_id
                JOIN      sys.objects AS obj
                ON        col.object_id = obj.object_id
                JOIN      sys.schemas AS scm
                ON        obj.schema_id = scm.schema_id
                LEFT JOIN sys.default_constraints def
                ON        col.default_object_id = def.object_id
                AND       col.object_id = def.parent_object_id
                LEFT JOIN sys.extended_properties AS prop
                ON        obj.object_id = prop.major_id
                AND       col.column_id = prop.minor_id
                AND       prop.name = 'MS_Description'
                WHERE     obj.type = 'U'
                AND       (obj.name = 'column_change_type_test' AND scm.name = SCHEMA_NAME())' Params: 
3. SQL: 'ALTER TABLE column_change_type_test ADD CONSTRAINT DF_A74995E2_BF396750 DEFAULT 5 FOR id' Params: 
2. SQL: 'CREATE TABLE column_change_type_test (id INT NOT NULL)' Params: 

Trace:
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Connection.php:988
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:971
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:612
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\SQLServerSchemaManager.php:232
C:\projects\doctrine\dbal\tests\Doctrine\Tests\DBAL\Functional\Schema\SchemaManagerFunctionalTestCase.php:621
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:976
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:831
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:776
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php:176
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:268
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:506

#0 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\DBALException))
#1 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest))
#3 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), false, Array, Array, false)
#6 C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9 {main}



 Comments   
Comment by Thomas Müller [ 03/Mar/14 ]

Possible solution: http://www.select-sql.com/mssql/how-to-alter-column-with-default-constraint-in-mssql.html

Comment by Thomas Müller [ 03/Mar/14 ]

Here is the unit test: https://github.com/DeepDiver1975/dbal/commit/53238301f7e124d31232e9b3eab774c32c9e04c4

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

Thomas Müller Thanks for reporting. Which version of SQL Server is affected by this?

Comment by Thomas Müller [ 03/Mar/14 ]

SQL Server 2012 Express Edition

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

Fixed in commit: https://github.com/doctrine/dbal/commit/171a8762673ee61a89e3d6ce891cd2b475e7b5f7





[DBAL-826] [GH-536] [WIP] unit test for DBAL-825 Created: 03/Mar/14  Updated: 08/May/14  Resolved: 07/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: sqlserver, sqlsrv

Issue Links:
Duplicate
duplicates DBAL-825 ALTER COLUMN on mssql is failing if d... Resolved
is duplicated by DBAL-833 [GH-542] [DBAL-825] Drop default cons... Resolved

 Description   

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

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

Message:

Here is the unit test for http://www.doctrine-project.org/jira/browse/DBAL-825

Let's see if I can come up with a solution as well ....



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

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

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

Duplicated by DBAL-825 and addressed in DBAL-833

Comment by Doctrine Bot [ 08/May/14 ]

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





[DBAL-848] [GH-553] [DBAL-843] Fix reverse engineering LOB type column types in MySQL Created: 25/Mar/14  Updated: 08/May/14  Resolved: 08/May/14

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

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

Issue Links:
Duplicate
duplicates DBAL-843 Doctrine DBAL getSchema() detect wron... Resolved

 Description   

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

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

Message:

This PR fixes reverse engineering the length of `TextType` / `BlobType` columns in MySQL which is important for proper SQL generation of distinct native `TINYTEXT`, `TEXT`, `MEDIUMTEXT`, `LONGTEXT`, `TINYBLOB`, `BLOB`, `MEDIUMBLOB` and `LONGBLOB` types.



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

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

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

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





[DBAL-843] Doctrine DBAL getSchema() detect wrong text type (LONGTEXT instead of TEXT) Created: 22/Mar/14  Updated: 08/May/14  Resolved: 08/May/14

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

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

Issue Links:
Duplicate
is duplicated by DBAL-848 [GH-553] [DBAL-843] Fix reverse engin... Resolved

 Description   

I created a database from Doctrine Schema (refer as "expected schema" in the text below) which worked fine. Later I need to compare the "expected schema" with the "current schema" from the database. While I am doing that I figured out the the SQL statements of both schemas differs. While the "expected schema" defines a TEXT type for a field, the "current schema" defines a LONGTEXT for the field.

Here is what I am doing:
$tableName = $schema->createTable('tableName');
$tableName->addColumn('fieldName', 'text', array('length' => 65535, 'notnull' => FALSE));

$currentSchema = $connection->getSchemaManager()->createSchema();
$currentSQL = $currentSchema->toSql($connection->getPlatform());

// CREATE TABLE tableName (fieldName LONGTEXT DEFAULT NULL) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

$expectedSchema = $this->getExpectedSchema();
$expectedSQL = $expectedSchema->toSql($connection->getPlatform());
// CREATE TABLE tableName (fieldName TEXT DEFAULT NULL) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

This happens because in Doctrine/DBAL/Schema/MySqlSchemaManager.php the type of text is detect correctly but the length is set to FALSE instead of 65535 and when it comes to create the SQL string from the schema it just returns LONGTEXT because the variable $length is FALSE (See Doctrine/DBAL/Platforms/MySqlPlatform::getClobTypeDeclarationSQL().

I added a new case in MySqlSchemaManager::_getPortableTableColumnDefinition which set the length of text types to 65535 and it works. I don't know if this is the correct place in code to do that.

Maybe you can point at the correct place and I will create a PR at Github.



 Comments   
Comment by Steve Müller [ 22/Mar/14 ]

Stefano Kowalke which DBAL version are you using? As far as I can see the length is preserved for text type columns. See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L131-L160

Comment by Stefano Kowalke [ 22/Mar/14 ]

But there is no length information inside $tableColumn['type']. While the value of INT type in $tableColumn['type'] is 'int(11)', the value for TEXT type is just 'text'.

The number inside the parentheses is extracted in https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L111 for INT type but not for the TEXT type - line 111 returns and save FALSE in $length.

Comment by Steve Müller [ 25/Mar/14 ]

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

Comment by Stefano Kowalke [ 26/Mar/14 ]

Thanks for taking care of this.

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

Thanks for reporting

Comment by Doctrine Bot [ 08/May/14 ]

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

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

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





[DBAL-853] [GH-558] Fix integer 0 default value reverse engineering on SQL Anywhere Created: 31/Mar/14  Updated: 08/May/14  Resolved: 08/May/14

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

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


 Description   

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

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

Message:

If an integer column was created with a default value of `0`, SQL Anywhere reverse engineers the default value to `null`. This is fixed by this PR.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/5cbe3ce87d4490cb61a3abc59b24f3dc07a2395e





[DBAL-901] [GH-601] Could not retrieve columns for a table with quotes on PostgreSQL Created: 08/May/14  Updated: 08/May/14  Resolved: 08/May/14

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

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

Issue Links:
Duplicate
duplicates DBAL-874 [GH-572] Fix reverse engineering quot... Resolved

 Description   

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

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

Message:

If a table "user" exists in database, then it was not possible to retrieve
existing columns from that database, because we used to compare unquoted
table name with quoted table name. This lead to schema that were out of sync
and could never be validated.



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

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

Comment by Adrien Crivelli [ 08/May/14 ]

This should be rejected in favor of DBAL-874, sorry for the noise.

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

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





[DBAL-874] [GH-572] Fix reverse engineering quoted table names on PostgreSQL Created: 22/Apr/14  Updated: 08/May/14  Resolved: 08/May/14

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

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

Issue Links:
Duplicate
is duplicated by DBAL-901 [GH-601] Could not retrieve columns f... Resolved

 Description   

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

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

Message:

Commit https://github.com/doctrine/dbal/commit/83fe296de44ef3e2f04f2342021f656a797787ec introduced a bug with reverse engineering table details for tables with names requiring quotation (reserved keyword, non-identifier characters, case-folded) on PostgreSQL.
`PostgreSqlPlatform::getListTablesSQL()` fetches table names quoted if necessary with `quote_ident(tablename)` which in turn causes other `getListTable*SQL($table)` to fail retrieving results if the table name is quoted. Those methods always have to use unquoted table names in their statements.

See https://github.com/ZF-Commons/ZfcUserDoctrineORM/issues/77 for more details.



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

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

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

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





[DBAL-885] [GH-586] Change weird way of adding an entry to SplObjectStorage Created: 29/Apr/14  Updated: 05/May/14  Resolved: 05/May/14

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

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


 Description   

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

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

Message:



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

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





[DBAL-875] [GH-573] [DBAL-834] Fix order by with aggregate function(s) for limit/offset queries on SQL Server Created: 23/Apr/14  Updated: 05/May/14  Resolved: 05/May/14

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

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

Issue Links:
Duplicate
duplicates DBAL-834 SQLServer modifyLimitQuery does not w... Resolved

 Description   

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

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

Message:

When modifying a query with limit/offset clauses on SQL Server, using aggregate functions, the platform generates wrong SQL.
See http://www.doctrine-project.org/jira/browse/DBAL-834



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/4a7ff71ec3b57af7d70f1180897502f8a156d59b





[DBAL-834] SQLServer modifyLimitQuery does not work with aggregate functions in ORDER BY Created: 10/Mar/14  Updated: 05/May/14  Resolved: 05/May/14

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

Type: Bug Priority: Major
Reporter: Francesco Montefoschi Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: paginator
Environment:

SQL Server 2008 SP3


Issue Links:
Duplicate
duplicates DBAL-788 ORDER BY with function COUNT() fails Resolved
is duplicated by DBAL-875 [GH-573] [DBAL-834] Fix order by with... Resolved

 Description   

Starting with Doctrine 2.4, the `modifyLimitQuery` method does not work anymore with query using ORDER BY MAX(...)
See this example:

$sql = "SELECT MAX(heading_id) aliased, code
	FROM operator_model_operator
	GROUP BY code
	ORDER BY MAX(heading_id) DESC
";
$sql = $this->em->getConnection()->getDatabasePlatform()->modifyLimitQuery(
	$sql, 1, 0
);

Doctrine generates this SQL, which is invalid:

SELECT * FROM (SELECT MAX(heading_id) aliased, code
, ROW_NUMBER() OVER (ORDER BY MAX(heading_id) AS doctrine_rownum FROM operator_model_operator GROUP BY code) DESC
) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1

The ORDER BY in moved into the OVER(), but the `preg_replace` in SQLServerPlatform.php stops to replace at the closing ")".



 Comments   
Comment by Francesco Montefoschi [ 10/Mar/14 ]

It is not possible to write `ORDER BY aliased` because it leads to a syntax error in SQL Server.

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

Francesco Montefoschi There have been some modifications to the modifyLimitQuery() method in SQL Server lately for 2.5 which address some problems with subqueries and aggregate functions. Not sure if that might already solve your issue. Can you please check if the problem also exists in the current master branch of DBAL?
See commit: https://github.com/doctrine/dbal/commit/9f3cb437c0f491599de4e1bd847235965f98ffd4

Comment by Francesco Montefoschi [ 11/Mar/14 ]
  - Removing doctrine/common (v2.4.1)
  - Installing doctrine/common (2.4.x-dev 9a7e20e)
    Cloning 9a7e20e779360f3b8a02c27a89d47d5a6fdce8d1

  - Removing doctrine/dbal (v2.4.2)
  - Installing doctrine/dbal (dev-master c61361d)
    Cloning c61361d8fcf65a977d8610ba78eb542a1d2f44b4

  - Removing doctrine/orm (v2.4.2)
  - Installing doctrine/orm (2.4.x-dev a949e87)
    Cloning a949e87ca88299cde368d2b574740753526b62c9

Same issue.

Comment by Flip [ 14/Mar/14 ]

on this line here https://github.com/doctrine/dbal/blob/9f3cb437c0f491599de4e1bd847235965f98ffd4/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php#L1164

try the following stuffs:

Puts "DESC" in a second capturing group (closer to the original regex, but not sure why you want to do this)
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?)(.*)/

Includes "DESC" in the first capturing group
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?.*)/

Same as last one, except this one stops capturing when it hits a ")" after "DESC"
/ORDER\s+BY\s+([^)(]*(?:\(\w+\))?[^)]*)/
Comment by M.K. [ 21/Mar/14 ]

This not only affects Queries with aggregate functions, but every Query that uses a limit and order by an entity-field alias.

Try this Testcase:

$query = $this->em->createQuery("
	SELECT a.id AS test
	FROM prim\\entity\\Article a
	ORDER BY test ASC
");
$query->setMaxResults(10);
echo "<h3>DQL</h3>";
var_dump($query->getDQL());
echo "<br><h3>SQL</h3>";
var_dump($query->getSQL());
echo "<br><h3>Result</h3>";
var_dump($query->getResult());
Comment by Flip [ 21/Mar/14 ]

The test case is incomplete as we don't have `kare\\entity
Article`. Please try the 3 proposed solutions and show the results from those adjustments.

Comment by M.K. [ 21/Mar/14 ]

This is just a sample Query for illustration. Replace it with whatever Entity you like.

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

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

Francesco Montefoschi Flip M.K. please review.

Comment by Francesco Montefoschi [ 28/Apr/14 ]

Hi Steve,

I tried 2.5.*@dev now and everything works for me.
About the code, I am not a regexp guru.

Just for review purpose, can you explain this regexp?
https://github.com/deeky666/dbal/commit/df1f3e4ce13eed6d0a406f34ea3174711531edae#diff-8a544d213159863ef39497f4b139b420R1155

Thank you.

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

The regex replaces the ORDER BY including nested parentheses expressions (uses recursion for that) until a terminating sequence is detected (for example a closing parenthesis that has no corresponding opening parenthesis from a previous ORDER BY expression.
This might not be perfect and complete but it is an improvement. It does not stop matching after the first closing parenthesis found.
Please note that the PR has not been merged yet so I am not sure whether you had the patch applied in your 2.5.*@dev version constraint.

Comment by Francesco Montefoschi [ 29/Apr/14 ]

Thank you Steve. I confirm you I tested your code (manually copied and pasted your patch to SQLServerPlatform in 2.5.*@dev ).
Maybe it is not perfect, but surely a huge improvement.

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

Alright. Thanks for testing.

Comment by M.K. [ 02/May/14 ]

I've had no time for testing this yet, but i read your code changes and i think this is definitely a big step forward. But it would be a lot nicer if you could always ORDER BY an alias in DQL. DBAL's goal is abstract away database specific language and for now users still have to worry about the Platform while writing DQL queries with ORDER BY :/

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

I'm not sure if I understand correctly. Can you please give an example of what you mean? It sounds like it's another issue?

Comment by M.K. [ 02/May/14 ]
SELECT MAX(heading_id) aliased, code
FROM operator_model_operator
GROUP BY code
ORDER BY aliased DESC

This Query won't work with modifyLimitQuery

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

M.K. Okay I think I get what you mean but that is another issue IMO. There should be a new ticket for this.

Comment by Francesco Montefoschi [ 05/May/14 ]

Can we merge this in master/2.5?

Comment by Doctrine Bot [ 05/May/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/4a7ff71ec3b57af7d70f1180897502f8a156d59b





[DBAL-788] ORDER BY with function COUNT() fails Created: 08/Jan/14  Updated: 05/May/14  Resolved: 05/May/14

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

Type: Bug Priority: Major
Reporter: Flip Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: None
Environment:

mssql 2008 R2


Issue Links:
Duplicate
is duplicated by DBAL-834 SQLServer modifyLimitQuery does not w... Resolved

 Description   

This:
ORDER BY ad.name ASC, count(filter.value) DESC

Fails with:
Error: Expected end of string, got '('



 Comments   
Comment by M.K. [ 15/Jan/14 ]

I have the same problem using SUM() in ORDER BY. I think the doctrine documentation says, that you have to use an alias in ORDER BY. This works fine with MySQL, but fails in MSSQL, because MSSQL doesn't allow aliases in ORDER BY.
I think using aliases in DQL should be fine, so it's rather a problem in SQLServerPlatform class. Aggregate functions in ORDER BY are pretty basic stuff.

Issue should be moved to DBAL.

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

Is using aggregate functions in ORDER BY even possible in SQL Server? It's not clear from the documentation. However it looks like ORDER BY SQL generation might have to be delegated to the specific platform just like LIMIT/OFFSET clauses. This would be another big mess for SQL Server

Comment by M.K. [ 15/Jan/14 ]

I use MSSQL 2008 R2 as well and it seems MSSQL is fine with using aliases in ORDER BY after all. If i run a DQL-Query like that:

SELECT t.id, SUM(pos.price) AS amount
FROM Project\Entity\Task t
LEFT JOIN Project\Entity\Position pos WITH t.id = pos.tid
GROUP BY t.id
ORDER BY amount ASC

... everything is fine. SQL looks like this:

SELECT t0_.id AS id0, SUM(p0_.price) AS sclr1
FROM task t0_ WITH (NOLOCK)
LEFT JOIN position p0_ ON (t0_.id = p0_.tid)
GROUP BY t0_.id
ORDER BY sclr1 ASC

MSSQL seems to be okay with the alias. But if apply a limit on the DQL-Query, SQL looks like this:

SELECT *
FROM (
	SELECT t0_.id AS id0, SUM(p0_.price) AS sclr1, ROW_NUMBER() OVER (ORDER BY sclr1 ASC) AS doctrine_rownum
	FROM task t0_ WITH (NOLOCK)
	LEFT JOIN position p0_ ON (t0_.id = p0_.tid)
	GROUP BY p0_.id
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 50

Execution fails with Error: "Invalid column name 'sclr1'"

I'm not really familiar with MSSQL which is why i decided to use Doctrine after all. But i hope this helps.

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

M.K. Thanks for the detailed information. The fact that you are using a limit here was missing. SQL Server does not support referring to expressions or column aliases from the select list in OVER() clause.
See here: http://msdn.microsoft.com/en-us/library/ms189461.aspx
Could you please test if it possible to specify the SUM() expression directly in the OVER() clause? Like the following:

SELECT *
FROM (
	SELECT t0_.id AS id0, SUM(p0_.price) AS sclr1, ROW_NUMBER() OVER (ORDER BY SUM(p0_.price) ASC) AS doctrine_rownum
	FROM task t0_ WITH (NOLOCK)
	LEFT JOIN position p0_ ON (t0_.id = p0_.tid)
	GROUP BY p0_.id
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 50

If that works we might be able to rewrite the SQLServerPlatform::modifyLimitQuery() to respect that. Otherwise I really don't know what to do about it.

Comment by M.K. [ 15/Jan/14 ]

Yup, using the SUM() expression in the OVER() clause works just fine.

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

M.K. Thank you for investigating. I would like to move this ticket to DBAL because it is a DBAL issue. But I guess that makes two issues now because if I understand correctly, Flip did not use a limit/offset query modification but did not use an alias in the ORDER BY clause either but instead directly specified a COUNT() expression...

Comment by Flip [ 24/Jan/14 ]

I can confirm it works when using an alias. Issue can be closed.

Comment by M.K. [ 14/Mar/14 ]

This issue refers to the same problem:
http://www.doctrine-project.org/jira/browse/DBAL-834

Comment by Doctrine Bot [ 05/May/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/4a7ff71ec3b57af7d70f1180897502f8a156d59b





[DBAL-892] [GH-593] Remove unused imports Created: 01/May/14  Updated: 02/May/14  Resolved: 02/May/14

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 02/May/14 ]

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





[DBAL-893] [GH-594] Fix driver exception conversion for newer SQLite versions Created: 02/May/14  Updated: 02/May/14  Resolved: 02/May/14

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

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


 Description   

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

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

Message:

As of [PHP 5.5.11](http://www.php.net/ChangeLog-5.php#5.5.11) the internal `libsqlite` has been upgraded to version `3.8.3.1` which seems to change some of the driver exception messages for constraint violations and causes [Travis to fail](https://travis-ci.org/doctrine/dbal/jobs/24234077#L187).
This PR now also matches strings to catch those appropriately.



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

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

Comment by Marco Pivetta [ 02/May/14 ]

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





[DBAL-891] [GH-592] Fix FQNs Created: 01/May/14  Updated: 01/May/14  Resolved: 01/May/14

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

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


 Description   

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

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

Message:



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

A related Github Pull-Request [GH-592] was closed:
https://github.com/doctrine/dbal/pull/592

Comment by Marco Pivetta [ 01/May/14 ]

Merged: https://github.com/doctrine/dbal/commit/dbff8249f0d887307edac7ab78ef79772f51f814





[DBAL-890] [GH-591] Improve param name Created: 01/May/14  Updated: 01/May/14  Resolved: 01/May/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/591

Message:



 Comments   
Comment by Doctrine Bot [ 01/May/14 ]

A related Github Pull-Request [GH-591] was closed:
https://github.com/doctrine/dbal/pull/591





[DBAL-889] [GH-590] Add a select method to Connection Created: 30/Apr/14  Updated: 30/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 JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/590

Message:

This is a draft; it has not been tested, not even manually.
It is meant for conceptual review



 Comments   
Comment by Doctrine Bot [ 30/Apr/14 ]

A related Github Pull-Request [GH-590] was closed:
https://github.com/doctrine/dbal/pull/590

Comment by Doctrine Bot [ 30/Apr/14 ]

A related Github Pull-Request [GH-590] was reopened:
https://github.com/doctrine/dbal/pull/590





[DBAL-888] [GH-589] Add missing @param tags Created: 29/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/589

Message:



 Comments   
Comment by Doctrine Bot [ 29/Apr/14 ]

A related Github Pull-Request [GH-589] was closed:
https://github.com/doctrine/dbal/pull/589





[DBAL-884] [GH-585] Fix incorrect reference to PDO in DB2Statement Created: 29/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/585

Message:



 Comments   
Comment by Doctrine Bot [ 29/Apr/14 ]

A related Github Pull-Request [GH-585] was closed:
https://github.com/doctrine/dbal/pull/585





[DBAL-882] [GH-583] Fix incorrect type hint in TableDiff Created: 29/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/583

Message:



 Comments   
Comment by Doctrine Bot [ 29/Apr/14 ]

A related Github Pull-Request [GH-583] was closed:
https://github.com/doctrine/dbal/pull/583





[DBAL-886] [GH-587] Remove plain wrong type hint where none is needed to begin with Created: 29/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/587

Message:



 Comments   
Comment by Marco Pivetta [ 29/Apr/14 ]

Merged: https://github.com/doctrine/dbal/commit/818622e64f8e0317079a4e751a655cc25ff77239

Comment by Doctrine Bot [ 29/Apr/14 ]

A related Github Pull-Request [GH-587] was closed:
https://github.com/doctrine/dbal/pull/587





[DBAL-880] [GH-581] Get rid of weird ternary statement Created: 29/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/581

Message:



 Comments   
Comment by Doctrine Bot [ 29/Apr/14 ]

A related Github Pull-Request [GH-581] was closed:
https://github.com/doctrine/dbal/pull/581

Comment by Marco Pivetta [ 29/Apr/14 ]

Merged: https://github.com/doctrine/dbal/commit/2f0027007a4bcd2c8292064458c77bd8c83719fc





[DBAL-881] [GH-582] Various doc imporvements in Index Created: 29/Apr/14  Updated: 29/Apr/14  Resolved: 29/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JeroenDeDauw:

Url: https://github.com/doctrine/dbal/pull/582

Message:



 Comments   
Comment by Doctrine Bot [ 29/Apr/14 ]

A related Github Pull-Request [GH-582] was closed:
https://github.com/doctrine/dbal/pull/582

Comment by Marco Pivetta [ 29/Apr/14 ]

Merged: https://github.com/doctrine/dbal/commit/120b30ba6861191b7e87e1b5cb59b18af66fca05





[DBAL-879] Sequence default value [PGSQL] Created: 29/Apr/14  Updated: 29/Apr/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mohammad Niknam Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: autoincrement, postgresql, sequence
Environment:

ArchLinux
PostgreSQL 9.3.4



 Description   

Hi
I'm using dbal to generate schmea from database via Schema-Manager. The problem is that my primary field 'id' have default value of 'nextval('test1_id_seq'::regclass)' but when I retrive columns using Doctrine\DBAL\Schema\AbstractSchemaManager::listTableDetails() or Doctrine\DBAL\Schema\Table::getColumns() , default value of the column 'id' is null.
In Doctrine\DBAL\Schema\PostgreSqlSchemaManager::_getPortableTableColumnDefinition() method at line 292 default value replaced with null, I don't know why but I guess It's because Driver compatibility.
Also Doctrine\DBAL\Schema\Sequence has no method to retrieve that table.
So I don't have the default value (pointing at sequence) and I can't find out what Sequence is linked to this table either.






[DBAL-876] [GH-574] Fixed the installation of HHVM nightly on Travis Created: 24/Apr/14  Updated: 25/Apr/14  Resolved: 25/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of stof:

Url: https://github.com/doctrine/dbal/pull/574

Message:

This is an attempt to fix the installation of HHVM nightly on Travis, which is failing because of dependency versions: https://travis-ci.org/doctrine/dbal/jobs/23685468

Once Travis updates its VM, we will get HHVM 3.0.1, but the process of deploying the new versions seems staled: https://github.com/travis-ci/travis-ci/issues/2126



 Comments   
Comment by Steve Müller [ 25/Apr/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/62e530073cba7c479b48c1d517565adfa6ba9d51





[DBAL-878] convert tool returns simplearray type instead of simple_array type Created: 24/Apr/14  Updated: 25/Apr/14  Resolved: 25/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4.2
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Minor
Reporter: Cedric Chandon Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux, Symfony 2.4



 Description   

With Symfony, when using
php app/console doctrine:mapping:convert
Types for simple_array are returned as simplearray without _



 Comments   
Comment by Guilherme Blanco [ 25/Apr/14 ]

Merged as of https://github.com/doctrine/doctrine2/commit/e8e86205f57db411fee17d65c4327f58c2be2655





[DBAL-805] [GH-524] Added new test WriteTest::testEmptyIdentityInsert(). Created: 06/Feb/14  Updated: 24/Apr/14  Resolved: 24/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Platforms
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of josemalonsom:

Url: https://github.com/doctrine/dbal/pull/524

Message:

I added a missing test for AbstractPlatform::getEmptyIdentityInsertSQL().



 Comments   
Comment by Doctrine Bot [ 24/Apr/14 ]

A related Github Pull-Request [GH-524] was closed:
https://github.com/doctrine/dbal/pull/524

Comment by Steve Müller [ 24/Apr/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/558a4ffb31640ffbda3e9e905c24bc9a219b7bf1





[DBAL-555] Table name is not quoted despite being a reserved word and being quoted in the annotation Created: 10/Jul/13  Updated: 24/Apr/14  Resolved: 21/Dec/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: mikeSimonson Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-802 Tablename quoting not working for ALT... Resolved

 Description   

When a reserved word is used as a table name the migration does half the job as far as the quoting is concerned.

The generated statement for the creation of the table doesn't work.
It generated:

 
CREATE TABLE Order .... # without quoting.

But when the table name is a reference in a foreign key it's ok.

 
ALTER TABLE Orders_Domains ADD CONSTRAINT FK_7FD78CA28D9F6D38 FOREIGN KEY (order_id) REFERENCES `Order` (id)
 
/**
 * @ORM\Table(name="`Order`")
 * @ORM\Entity
 */
class Order
{
}

I suppose that at some point the table name is unquoted but I didn't find out where.



 Comments   
Comment by Steve Müller [ 20/Nov/13 ]

Can you please tell which platform/driver you are using? Also the DBAL version would help tracking this down. But there has been done a lot of work concerning identifier quotation in the last months already so maybe this is already solved by 2.4?
Can you please reinvestigate? Thanks.

Comment by mikeSimonson [ 22/Nov/13 ]

Hi,

I was using doctrine-migration with the dbal 2.3.4.
How can I test for that before doctrine migration upgrade to the dbal 2.4

Thanks





[DBAL-802] Tablename quoting not working for ALTER TABLE Created: 06/Feb/14  Updated: 24/Apr/14  Resolved: 24/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.4, 2.4.2
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Dennis Birkholz Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: Quoting, TableDiff, mysql

Issue Links:
Duplicate
duplicates DBAL-555 Table name is not quoted despite bein... Resolved

 Description   

I use the orm:schema-tool:update to update the database schema of my model which contains a table with the name "Character".
Quoting for this table name works without the need to add backticks in foreign key definitions (references `Character`) but "ALTER Character" misses the quotes.
The reason is that the getAlterTableSQL method of the MySqlPlatform class uses the name property of the supplied TableDiff which does not contain a quoted name.
The original Table information that contained the quoting information is not available from the TableDiff.

A quick fix is to just force a name quoting with "$this->quoteIdentifier($diff->name)" in the getAlterTableSQL but this does ignore all quoting-decision-functionality of doctrine.



 Comments   
Comment by Dennis Birkholz [ 06/Feb/14 ]

Just checked on v2.4.2: the issue is still present there but the TableDiff now contains the original table information object so the fix may be a lot less hacky.

Comment by Steve Müller [ 06/Feb/14 ]

Dennis Birkholz This issue should have been fixed in 2.5, commit: https://github.com/doctrine/dbal/commit/75d35f5809095b37cb7085a9289eca4aa9c6df68
See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L600

Please check again with the current master.

Comment by Steve Müller [ 24/Apr/14 ]

Duplicate of http://www.doctrine-project.org/jira/browse/DBAL-555





[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-850] [GH-555] Improved performance of BlobType Created: 27/Mar/14  Updated: 24/Apr/14  Resolved: 24/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed 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/555

Message:

I noticed that the `string` to `resource` conversion code in `BlobType` uses a quite inefficient technique.
This PR improves its performance with a simple change involving the `php://temp` stream.

Quick benchmark of the two approaches, converting a 10MB string:

$value = str_repeat('x', 10 * 1024 * 1024);

$t = microtime(true);
$fp = fopen('data://text/plain;base64,' . base64_encode($value), 'r');
printf("%.3fs\n", microtime(true) - $t);

$t = microtime(true);
$fp = fopen('php://temp', 'rb+');
fwrite($fp, $value);
fseek($fp, 0);
printf("%.3fs\n", microtime(true) - $t);

Results on my laptop:

0.090s
0.008s

A tenfold improvement!



 Comments   
Comment by Doctrine Bot [ 24/Apr/14 ]

A related Github Pull-Request [GH-555] was closed:
https://github.com/doctrine/dbal/pull/555

Comment by Steve Müller [ 24/Apr/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/a0777077cbb8f60eaa780cd4a56644ffc5173c55





[DBAL-862] [GH-563] Lower case "order by" keyword causes wrong LIMIT query on SQL Server Created: 02/Apr/14  Updated: 24/Apr/14  Resolved: 24/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of stchr:

Url: https://github.com/doctrine/dbal/pull/563

Message:

SQLServerPlatform::modifyLimitQuery('SELECT * FROM user order by username')

(lowercase order by)
returns

SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY order) AS doctrine_rownum FROM user order by username) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10

instead of

SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY username) AS doctrine_rownum FROM user) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10


 Comments   
Comment by Doctrine Bot [ 24/Apr/14 ]

A related Github Pull-Request [GH-563] was closed:
https://github.com/doctrine/dbal/pull/563

Comment by Steve Müller [ 24/Apr/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/d6b91405c2cbee8e02eb16bb50df7a96d88a9315





[DBAL-868] [GH-566] added support of LOB download Created: 16/Apr/14  Updated: 22/Apr/14  Resolved: 22/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bborrel:

Url: https://github.com/doctrine/dbal/pull/566

Message:

OCI8Statement::bindParam() was forcing a LOB upload when passing a
parameter of a LOB type. Also, this forced upload is out of concern for
OCI8Statement::bindParam().

So I removed it to support LOB download. Now call of
oci_new_descriptor() to create a LOB is the responsibility of the
controller. To help this call I added OCI8Connection::getDBH() to be
able to get the resource to the connection.

File download example:
```
$connection = new \Doctrine\DBAL\Connection(...);
$sql = 'BEGIN APP.PKG_NAME.GET_FILE(:id,:data); END;';
$stmt = $connection->prepare($sql);
$stmt->bindValue('id', $id);

$blob = oci_new_descriptor($connection->getWrappedConnection()->getDBH(), OCI_DTYPE_LOB);
$stmt->bindParam('data', $blob, PDO::PARAM_LOB);

$stmt->execute();
$data = $blob->load();
```

File upload example:
```
$connection = new \Doctrine\DBAL\Connection(...);
$sql = 'BEGIN APP.PKG_NAME.PUT_FILE(:id,:bData); END;';
$stmt = $connection->prepare($sql);
$stmt->bindValue('id', $id);

$blob = oci_new_descriptor($connection->getWrappedConnection()->getDBH(), OCI_DTYPE_LOB);
$blob->writeTemporary($data, OCI_TEMP_BLOB);
$stmt->bindParam('data', $blob, PDO::PARAM_LOB);

$stmt->execute();
```



 Comments   
Comment by Doctrine Bot [ 22/Apr/14 ]

A related Github Pull-Request [GH-566] was closed:
https://github.com/doctrine/dbal/pull/566





[DBAL-824] [GH-535] added backtrace to query logging Created: 28/Feb/14  Updated: 22/Apr/14  Resolved: 22/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of dmecke:

Url: https://github.com/doctrine/dbal/pull/535

Message:

I've added a stacktrace to each logged query to be able to display it later on. This can help to find out why a query has been executed.



 Comments   
Comment by Doctrine Bot [ 21/Apr/14 ]

A related Github Pull-Request [GH-535] was closed:
https://github.com/doctrine/dbal/pull/535

Comment by Guilherme Blanco [ 21/Apr/14 ]

You can create your own Logger for this support.
Adding this have resources usage implication and therefore cannot be blindly added.
I also see a potential serialization issue depending on the driver used to log this information.

Closing as won't fix.

Comment by Marco Pivetta [ 22/Apr/14 ]

Fixed resolution status





[DBAL-873] [GH-571] Introduced a Transaction object Created: 18/Apr/14  Updated: 18/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 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!






[DBAL-872] [GH-570] Add support for out cursor in OCI8 Created: 18/Apr/14  Updated: 18/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 Juliens:

Url: https://github.com/doctrine/dbal/pull/570

Message:

I don't know if it is the best solution, but it's a beginning.






[DBAL-871] [GH-569] Fixed type and initialization value of $_nestTransactionsWithSavepoints Created: 17/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/dbal/pull/569

Message:

`Connection::$_nestTransactionsWithSavepoints` is definitely a `boolean` and not an `integer`, and the rest of the code assumes it's `false` by default, whereas it's actually `null` right now. Which still works as `null` evaluates as `false`, but is not clean.



 Comments   
Comment by Doctrine Bot [ 18/Apr/14 ]

A related Github Pull-Request [GH-569] was closed:
https://github.com/doctrine/dbal/pull/569

Comment by Guilherme Blanco [ 18/Apr/14 ]

Issue got merged





[DBAL-870] [GH-568] Removed unused imports and unnecessary FQCN Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/dbal/pull/568

Message:



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

A related Github Pull-Request [GH-568] was closed:
https://github.com/doctrine/dbal/pull/568

Comment by