[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 Marco Pivetta [ 17/Apr/14 ]

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





[DBAL-869] [GH-567] Fixed Configuration::getSQLLogger() return type 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: 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 BenMorel:

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

Message:

`getSQLLogger()` can return `null`, this was omitted.



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

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

Comment by Marco Pivetta [ 17/Apr/14 ]

Merged: https://github.com/doctrine/dbal/commit/32c5a3ea7060d8f3edd29907fd324433ea265996





[DBAL-868] [GH-566] added support of LOB download Created: 16/Apr/14  Updated: 16/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 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();
```






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

Status: Open
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: Benjamin Eberlei
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






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

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

Type: Bug Priority: Major
Reporter: Christian Stoller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
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?






[DBAL-865] [GH-565] fix lastInsertId typehint in SqlSrv Created: 12/Apr/14  Updated: 13/Apr/14  Resolved: 13/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: Marco Pivetta
Resolution: Fixed 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/565

Message:

An LastInsertId|null is expected.



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

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

Comment by Marco Pivetta [ 13/Apr/14 ]

Merged: https://github.com/doctrine/dbal/commit/32817aac490eeba4c39bd7670ec2f6182e496fc5





[DBAL-864] Failure to insert FALSE into a bool column Created: 10/Apr/14  Updated: 11/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: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved 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();




[DBAL-863] [GH-564] [DBAL-630] Incorrect PostgreSQL boolean handling Created: 04/Apr/14  Updated: 07/Apr/14

Status: Awaiting Feedback
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: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: boolean, dbal, orm, postgresql


 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.





[DBAL-862] [GH-563] Lower case "order by" keyword causes wrong LIMIT query on SQL Server Created: 02/Apr/14  Updated: 02/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 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





MsSQL-Server DateTime microseconds issue (DBAL-860)

[DBAL-861] ensure the dateformat Y-m-d gets used by the MsSQL-Server 2005 Created: 14/Feb/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Sub-task Priority: Major
Reporter: Martin Weise Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

php5.3.5; MsSQL-Server 2005; W2K8; Apache2; MS pdo_sqlsrv_ts_vc6 driver



 Description   

To ensure that the MsSQL-Server 2005 (and maybe higher) uses the format that is specified in the MsSqlPlatform class (Y-m-d)
set it via 'SET DATEFORMAT ymd' .

This should be done directly after the connection has be opened.



 Comments   
Comment by Martin Weise [ 14/Feb/11 ]

Issue created as wished from Juozas Kaziukenas.

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

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





[DBAL-860] MsSQL-Server DateTime microseconds issue Created: 11/Feb/11  Updated: 01/Apr/14  Resolved: 09/Jan/12

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

Type: Bug Priority: Major
Reporter: Martin Weise Assignee: Juozas Kaziukenas
Resolution: Fixed Votes: 0
Labels: None
Environment:

WindowsXP/Windows2008 R2 / PHP 5.3 / MsSQL-Server 2005 / MsSQL-PDO_PHP-Driver


Sub-Tasks:
Key
Summary
Type
Status
Assignee
DBAL-861 ensure the dateformat Y-m-d gets used... Sub-task Resolved Benjamin Eberlei  

 Description   

The string for the function getDateTimeFormatString() in the MsSqlPlatform class is 'wrong'.
The Microsoft-SQL-Server just uses 3 digits for microseconds and not 6.
So the string 'Y-m-d H:i:s.u' fails and the server states: [SQL Server]Fehler beim Konvertieren einer Zeichenfolge in einen datetime-Wert (Error when converting a string to a datetime-value) .

So this string works, but does not regard the microseconds for those how rely on them: 'Y-m-d H:i:s.000'

See also:
[...] The MS datetime column is documented to have an accuracy of only about .3 seconds anyway [...]
http://bytes.com/topic/sql-server/answers/80150-inserting-datetime-milliseconds-sql-server

http://msdn.microsoft.com/en-gb/library/ms186819.aspx (Section: Remarks)



 Comments   
Comment by Benjamin Eberlei [ 11/Feb/11 ]

Assigned to juozas, but i think the issue here is that you have to use Datetime2, or add your own type replacing the shipped one to support the old datetime.

Comment by Martin Weise [ 14/Feb/11 ]

Ok, I had another problem with the datetime, but this does not regard the problem of this issue ( at least not totally).
The problem with the MsSQL-Server before 2008 is that there is no data type named 'datetime2', just 'datetime'.
The next problem is that every date conversion for a query is done in the language set upon conection time.
Thus leads to a problem, when it is not possible to set the connection language.

So the problem is that the MsSQL-Server relies on the settings above.
In my case the datetime conversion failed, as the server always thought that the datetime-string would come in
the following format: Y-d-m . This is not true, as the default format string is: Y-m-d . So every insert/update query fails.
To solve the problem I did that: $entityManager->getConnection()->exec('SET DATEFORMAT ymd'); .
This way I ensured that the dateformat string works fine, except the issue problem.

To solve the problem in general, it would be helpful to subclass the MsSqlPlatform into a class named MsSql2005Platform or something like this and just override the getDateTimeFormatString and upon connection setting the format for the queries
as mentioned before.

Hope this helps out.
Besides, here a link to the datetime problem (in german): http://www.insidesql.org/blogs/frankkalis/2010/08/19/der-ultimative-guide-fuer-die-datetime-datentypen

Comment by Juozas Kaziukenas [ 14/Feb/11 ]

I have somehow manage to miss the fact that datetime2 wasn't around in datetime... What I'm thinking now is there a need for datetime2 in Doctrine at all. If only thing it brings is additional accuracy for microseconds, maybe best idea would be to use datetime for 2008 installs too if used from Doctrine. However datetime is now a standard and Microsoft recommends to use it for new installs. What I can do is I can always insert 3 fractional points to datetime column as both datetime2 and datetime would accept it as valid date string.

We can have separate platforms for 2008 and 2005 servers, but that would be quite resource intensive. Let me see what is the best way to fix it.

Regards to Dateformat, I guess the solution would be to set format on connection, how you suggested. How about you create a separate ticket for this and assign it to me.

Comment by Benjamin Eberlei [ 14/Feb/11 ]

Oracle also has an Session Init Listener that handles the date format things, i guess we can take this as example. However I think having Mssql2005Platform sounds goods also, it would be only one method to override.

Comment by Martin Weise [ 09/Aug/11 ]

To solve this issue, at least for MsSQL-Server datetime data types, change the following TypeClass of Doctrine by adding
this check before converting to PHP\DateTime in 'convertToPHPValue()' :

if( strlen($value) == 24 && $platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u')
$value = $value.'000';

I know this is propably very specific, but I do not know, how other DBs handle microseconds in datetime strings.

Comment by Martin Weise [ 08/Sep/11 ]

I fixed this bug with some changes in the DateTimeType class. As there is no Explicit MSSQL2005 Plattform this change would also affect datetime2 type in the SQLServer 2008 plattform, which is the data type that has 6 microseconds.
So either populate a MSSQLServer2005 Plattform, or introduce a new DateTimeType for the 2005 platform.

DateTimeType.php

<?php
/*
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 * This software consists of voluntary contributions made by many individuals
 * and is licensed under the LGPL. For more information, see
 * <http://www.doctrine-project.org>.
 */

namespace Doctrine\DBAL\Types;

use Doctrine\DBAL\Platforms\AbstractPlatform;

/**
 * Type that maps an SQL DATETIME/TIMESTAMP to a PHP DateTime object.
 *
 * @since 2.0
 */
class DateTimeType extends Type
{
    public function getName()
    {
        return Type::DATETIME;
    }

    public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        return $platform->getDateTimeTypeDeclarationSQL($fieldDeclaration);
    }

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
		if( $value === null)
			return null;

		$value = $value->format($platform->getDateTimeFormatString());

		if( strlen($value) == 26 &&
			$platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u' &&
			$platform instanceof \Doctrine\DBAL\Platforms\MsSqlPlatform )
			$value = substr($value, 0, \strlen($value)-3);

		return $value;

    }

    public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        if ($value === null) {
            return null;
        }

		if( strlen($value) == 24 && $platform->getDateTimeFormatString() == 'Y-m-d H:i:s.u')
			$value = $value.'000';

        $val = \DateTime::createFromFormat($platform->getDateTimeFormatString(),$value);
        if (!$val) {
            throw ConversionException::conversionFailedFormat($value, $this->getName(), $platform->getDateTimeFormatString());
        }
        return $val;
    }
}

Comment by Benjamin Eberlei [ 09/Jan/12 ]

Added SQLServer2005 platform that uses DATETIME and the .000 format as per instructions of Martin.





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

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved 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.





[DBAL-858] oracle IN statement with more than 1000 values Created: 11/Jan/13  Updated: 01/Apr/14

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

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


 Description   

If I have a query with a IN statement with more tahn 1000 values I get an sql error.

I've try IN with implode:
select * from test where id IN(' . implode(',', $values) . ')
and I've also try with executeQuery:
select * from test where id IN(:test)
executeQuery($sql, array($values), array(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY))



 Comments   
Comment by Marc Drolet [ 11/Jan/13 ]

Here is the way I've implement the solution on my side: (for oracle)

into Doctrine/DBAL/Statement.php, I've add this method:

/**
     * Binds a parameter value to the statement.
     * This is implemented this way for oracle only. Other drivers are redirected to bindValue method.
     *
     * The value will be bound with to the type provided (that required to be a table type).
     *
     * @param String $name The name or position of the parameter.
     * @param Array $value The value of the parameter.
     * @param String $type The name of the type to use to bind.
     * @return boolean TRUE on success, FALSE on failure.
     */
    public function bindList($name, Array $value, $type)
    {
        if ('oracle' !== $this->platform->getName())
        {
            $this->bindValue($name, $value, $type);
        }
        else
        {
            return $this->stmt->bindList($name, $value, $type);
        }
    }

into Doctrine/DBAL/Driver/Statement.php I've add:

/**
     * @TODO: docs
     */
    function bindList($param, Array $values, $type);

into Doctrine/DBAL/Driver/OCI8/OCI8Statement.php I've add this method:

/**
     * {@inheritdoc}
     */
    public function bindList($param, Array $value, $type)
    {
        if (!($list = oci_new_collection($this->_dbh, $type)))
        {
            //throw new OCI8Exception::fromErrorInfo($this->errorInfo());
        }

        foreach ($value as $entry)
        {
            $list->append($entry);
        }
        if (!oci_bind_by_name($this->_sth, $param, $list, -1, OCI_B_NTY))
        {
            //throw new OCI8Exception::fromErrorInfo($this->errorInfo());
        }
    }

// NOTE: we should probably add the bindList to all driver Statement object.

into your code you can use it this way:

$sql = "
    SELECT *
    FROM test
    WHERE id IN
    (
        SELECT *
        FROM
        (
            CAST (: p_ids AS list_int_type)
        )
    )
";
$stmt = connection->prepare($sql);
$stmt->bindList(': p_ids', $ids, 'list_int_type');
$stmt->execute();
$rs = $stmt->fetchAll(PDO::FETCH_ASSOC);

NOTE:
list_int_type need to be a valid oracle data type. You can create one with the name you want.
example:
you can have 2 type of accepted array of values: integer and string
let's say we create one for string named: list_str_type and one for integer list_int_type

create or replace type list_str_type as table of varchar2(4000);
create or replace type list_int_type as table of number;

Comment by Benjamin Eberlei [ 01/Apr/13 ]

Hey Marc Drolet

thanks for the feedback and the solution, however i would like to have something generic that is working independent of the database driver. This code is very specific.

Can you point me to some documentation why oci collection works with more than 1000 elements and how it works in PHP?

Comment by Marc Drolet [ 02/Apr/13 ]

Hi Benjamin,

The limitation is not from the oci driver, it's an oracle limitation. There are a couple of possible solution/implementation that can be done but the one I've provide is the one that perform better for the test I've done and from what I can found over the blogs I've read.

I can't find the exact documentation of oracle. oracle doc is so poor.
Here is the best description link I can provide that describe some possible implementation.
http://vsadilovskiy.wordpress.com/substituting-a-collection-for-in-list-performance-study/

I don't know if there is similar limitation with other database. With the implementation I've provided, It will be possible to implement the proper solution depending on the database limitation you face otherwise it will execute the generic IN. What's bad, we need to create the type into the database.

NOTE: In my case, I can not perform a sub-query, I get the my collection from a web service call.





[DBAL-857] [GH-562] Fix TRIM expression Created: 31/Mar/14  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

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


 Description   

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

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

Message:

The `TRIM` expression is broken on SQL Anywhere and while fixing it and writing functional tests for testing the `TRIM` expression on all platforms, I realized that it is seriously broken in `AbstractPlatform`, too.
We have prove now through the tests that it works as expected.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/3986daf9fa0b18ee1d0f4ec12bacf057b4be5c44





[DBAL-856] [GH-561] Fix FOR UPDATE SQL on SQL Anywhere Created: 31/Mar/14  Updated: 31/Mar/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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.






[DBAL-855] [GH-560] Fix DateTimeTz type compatibility on SQL Anywhere versions < 12 Created: 31/Mar/14  Updated: 31/Mar/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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.






[DBAL-854] [GH-559] Fix LOCATE expression on SQL Anywhere and SQLite Created: 31/Mar/14  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

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


 Description   

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

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

Message:

This fixes an error in the `LOCATE` expression on SQL Anywhere by using the native `LOCATE` SQL function now, as well as an error with the `LOCATE` expression on SQLite where the offset was evaluated incorrectly.
Also added functional tests to finally verify this stuff.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/0833d00b1c3674b49091221491ba55f00424711c





[DBAL-853] [GH-558] Fix integer 0 default value reverse engineering on SQL Anywhere Created: 31/Mar/14  Updated: 31/Mar/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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.






[DBAL-852] [GH-557] fix date format on oracle Created: 28/Mar/14  Updated: 28/Mar/14  Resolved: 28/Mar/14

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

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


 Description   

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

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

Message:

The expected format for DATE columns is `01-MAR-14`. See http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT413

It also works with `01-Mar-2014` as this PR uses.

We found the problem when trying something like

```
$this->oracleCon->executeQuery(
'SELECT * FROM table WHERE datefield > ?',
array(new \DateTime()),
array(Type::DATE)
);
```

which was raising an oracle error that the date could not be parsed.

The



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

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





[DBAL-851] [GH-556] fix date format on oracle Created: 28/Mar/14  Updated: 28/Mar/14  Resolved: 28/Mar/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 Tobion:

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

Message:



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

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





[DBAL-850] [GH-555] Improved performance of BlobType Created: 27/Mar/14  Updated: 27/Mar/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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!






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

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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'






[DBAL-848] [GH-553] [DBAL-843] Fix reverse engineering LOB type column types in MySQL Created: 25/Mar/14  Updated: 25/Mar/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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.






[DBAL-847] [GH-552] Quote create update and delete methods Created: 25/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/14

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

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


 Description   

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

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

Message:

Add quote for field names.



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-846] [GH-551] Foreign key checks on MySQL >= 5.5.7 for TRUNCATE Created: 24/Mar/14  Updated: 24/Mar/14

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

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


 Description   

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

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

Message:

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

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






[DBAL-845] [GH-550] Type specification Created: 22/Mar/14  Updated: 22/Mar/14  Resolved: 22/Mar/14

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

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


 Description   

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

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

Message:

To avoid warning when extend this class.



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

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

Comment by Marco Pivetta [ 22/Mar/14 ]

Won't be fixed in 2.x





[DBAL-844] [GH-549] Fix truncate on MySQL >= 5.5 Created: 22/Mar/14  Updated: 22/Mar/14

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

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


 Description   

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

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

Message:

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

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

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

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

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

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






[DBAL-843] Doctrine DBAL getSchema() detect wrong text type (LONGTEXT instead of TEXT) Created: 22/Mar/14  Updated: 26/Mar/14

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

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


 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





[DBAL-842] [GH-548] DBAL-774 - added failing test for parsing order of joins Created: 21/Mar/14  Updated: 21/Mar/14

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

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


 Description   

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

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

Message:

I had finaly some time to investigate the problem a bit more, and the problem is the way doctrine/dbal >= 2.4 handles the parsing of joins

The expected result is the way doctrine/dbal 2.3 handles the joins, which is not quite the way i expect that the query would be outputted but it is correct for execution.



 Comments   
Comment by Jeroen Thora [ 21/Mar/14 ]

Pullrequest related to DBAL-774





[DBAL-841] [GH-547] Add the instancename parameter for oci8 driver Created: 19/Mar/14  Updated: 25/Mar/14  Resolved: 19/Mar/14

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

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

Issue Links:
Reference
relates to DBAL-838 [GH-544] ORACLE, (INSTANCE_NAME = XXXXX) Resolved

 Description   

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

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

Message:

We add the instancename parameter documentation for oci8 driver



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

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

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

Part of PR: https://github.com/doctrine/dbal/pull/544

Comment by Doctrine Bot [ 25/Mar/14 ]

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





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

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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).






[DBAL-839] [GH-545] [DBAL-835] Quote old column name in rename column SQL Created: 19/Mar/14  Updated: 19/Mar/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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).






[DBAL-838] [GH-544] ORACLE, (INSTANCE_NAME = XXXXX) Created: 18/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-841 [GH-547] Add the instancename paramet... Resolved

 Description   

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

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

Message:

Hello, first sorry for my English.
I need to put in the ORACLE Connection string to the parameter: (INSTANCE_NAME = XXXXX)

I was reading the source code at github and the latest version does not include this possibility in the method getEasyConnectString.

Could add to the next version an element in the array of parameters, eg $params['instance_name'] and concatenating that value to the Connection string?

Thank you, greetings
Facundo Panizza



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-837] Cannot drop index needed in a foreign key constraint Created: 17/Mar/14  Updated: 17/Mar/14

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

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

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


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

 Description   

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

The generated SQL is:

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

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

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

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

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



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

Maybe related to DBAL-732?





[DBAL-836] [GH-543] Clauses LEFT OUTER JOIN and RIGHT OUTER JOIN Created: 13/Mar/14  Updated: 14/Mar/14  Resolved: 14/Mar/14

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

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


 Description   

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

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

Message:

Added methods for construction of clauses LEFT OUTER JOIN and RIGHT OUTER JOIN



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

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





[DBAL-835] Old column name not quoted during column rename in MySQL Created: 12/Mar/14  Updated: 19/Mar/14

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

Type: Bug Priority: Major
Reporter: Arttu Manninen Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS with Doctrine 2.3 MySQL 5.5.31



 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





[DBAL-834] SQLServer modifyLimitQuery does not work with aggregate functions in ORDER BY Created: 10/Mar/14  Updated: 21/Mar/14

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

Type: Bug Priority: Major
Reporter: Francesco Montefoschi Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator
Environment:

SQL Server 2008 SP3



 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.





[DBAL-833] [GH-542] [DBAL-825] Drop default constraints before altering column type on SQL Server Created: 07/Mar/14  Updated: 07/Mar/14

Status: In Progress
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: Unresolved Votes: 0
Labels: sqlserver, sqlsrv

Issue Links:
Duplicate
duplicates DBAL-825 ALTER COLUMN on mssql is failing if d... In Progress
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





[DBAL-832] [GH-541] Allow mysql spatial indexes Created: 06/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Allows spatial indexes via the SPATIAL flag.
http://dev.mysql.com/doc/refman/5.7/en/creating-spatial-indexes.html



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





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

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

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


 Description   

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

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

Message:

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

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

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

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

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

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

{main}

````






[DBAL-830] [GH-539] unit test added for altering a column's default where the column name is... Created: 04/Mar/14  Updated: 05/Mar/14

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

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


 Description   

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

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

Message:

... a keyword - fails on mssql:

Exception : [Doctrine\DBAL\DBALException] An exception occurred while executing 'ALTER TABLE column_keyword_test DROP CONSTRAINT DF_D3D4D2F1_4BF2EAC0':

SQLSTATE [42000, 3728]: [Microsoft][SQL Server Native Client 11.0][SQL Server]'DF_D3D4D2F1_4BF2EAC0' is not a constraint.
SQLSTATE [42000, 3727]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Could not drop constraint. See previous errors.

With queries:
5. SQL: 'ALTER TABLE column_keyword_test DROP CONSTRAINT DF_D3D4D2F1_4BF2EAC0' Params: 
4. SQL: 'SELECT    col.name,
                          type.name AS type,
                          col.max_length AS length,
                          ~col.is_nullable AS notnull,
                          def.definition AS [default],
                          col.scale,
                          col.precision,
                          col.is_identity AS autoincrement,
                          col.collation_name AS collation,
                          CAST(prop.value AS NVARCHAR(MAX)) AS comment -- CAST avoids driver error for sql_variant type
                FROM      sys.columns AS col
                JOIN      sys.types AS type
                ON        col.user_type_id = type.user_type_id
                JOIN      sys.objects AS obj
                ON        col.object_id = obj.object_id
                JOIN      sys.schemas AS scm
                ON        obj.schema_id = scm.schema_id
                LEFT JOIN sys.default_constraints def
                ON        col.default_object_id = def.object_id
                AND       col.object_id = def.parent_object_id
                LEFT JOIN sys.extended_properties AS prop
                ON        obj.object_id = prop.major_id
                AND       col.column_id = prop.minor_id
                AND       prop.name = 'MS_Description'
                WHERE     obj.type = 'U'
                AND       (obj.name = 'column_keyword_test' AND scm.name = SCHEMA_NAME())' Params: 
3. SQL: 'ALTER TABLE column_keyword_test ADD CONSTRAINT DF_D3D4D2F1_ACF51D19 DEFAULT 23 FOR [select]' Params: 
2. SQL: 'CREATE TABLE column_keyword_test ([select] INT NOT NULL)' Params: 

Trace:
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Connection.php:988
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:971
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\AbstractSchemaManager.php:612
C:\projects\doctrine\dbal\lib\Doctrine\DBAL\Schema\SQLServerSchemaManager.php:232
C:\projects\doctrine\dbal\tests\Doctrine\Tests\DBAL\Functional\Schema\SchemaManagerFunctionalTestCase.php:619
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:976
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:831
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:776
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php:176
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:268
C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php:506

#0 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(946): Doctrine\Tests\DbalFunctionalTestCase->onNotSuccessfulTest(Object(Doctrine\DBAL\DBALException))
#1 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php(648): PHPUnit_Framework_TestCase->runBare()
#2 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php(776): PHPUnit_Framework_TestResult->run(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest))
#3 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(775): PHPUnit_Framework_TestCase->run(Object(PHPUnit_Framework_TestResult))
#4 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php(745): PHPUnit_Framework_TestSuite->runTest(Object(Doctrine\Tests\DBAL\Functional\Schema\SQLServerSchemaManagerTest), Object(PHPUnit_Framework_TestResult))
#5 C:\projects\doctrine\dbal\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php(349): PHPUnit_Framework_TestSuite->run(Object(PHPUnit_Framework_TestResult), false, Array, Array, false)
#6 C:\Program Files (x86)\PHP\v5.3\pear\PHPUnit\TextUI\Command.php(176): PHPUnit_TextUI_TestRunner->doRun(Object(PHPUnit_Framework_TestSuite), Array)
#7 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(268): PHPUnit_TextUI_Command->run(Array, true)
#8 C:\Users\deepdiver\AppData\Local\Temp\ide-phpunit.php(506): IDE_Base_PHPUnit_TextUI_Command::main()
#9 {main}





[DBAL-829] binding with PARAM_INT_ARRAY does not convert the values to integer Created: 04/Mar/14  Updated: 04/Mar/14  Resolved: 04/Mar/14

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

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


 Description   

When using PARAM_INT_ARRAY to bind values for 'in' clause
the resulting sql has quotes around the numbers

e.g. using query builder I have

$qb->setParameters(
array('id' => $pnums),
array('id' => Connection::PARAM_INT_ARRAY)
);

produces

"select .... from tableName where id in ('123','456','789')"

given that the array had numeric value as strings,
$ids = array('123','456','789');

but since we are specifying PARAM_INT_ARRAY, I think this should be taken care of by doctrine



 Comments   
Comment by Ananda Agrawal [ 04/Mar/14 ]

looks like PDO issue





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





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

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

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


 Description   

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

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

Message:

Remove lot of if making beautifull code using call_user_func_array






[DBAL-826] [GH-536] [WIP] unit test for DBAL-825 Created: 03/Mar/14  Updated: 07/Mar/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... In Progress
is duplicated by DBAL-833 [GH-542] [DBAL-825] Drop default cons... In Progress

 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





[DBAL-825] ALTER COLUMN on mssql is failing if default constraint is attached Created: 03/Mar/14  Updated: 07/Mar/14

Status: In Progress
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Thomas Müller Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MSSQL


Issue Links:
Duplicate
is duplicated by DBAL-833 [GH-542] [DBAL-825] Drop default cons... In Progress
is duplicated by DBAL-826 [GH-536] [WIP] unit test for DBAL-825 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





[DBAL-824] [GH-535] added backtrace to query logging Created: 28/Feb/14  Updated: 28/Feb/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 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.






[DBAL-823] [GH-534] [DBAL-813] Original PDOException is preserved Created: 23/Feb/14  Updated: 23/Feb/14  Resolved: 23/Feb/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:
Dependency
is required for DBAL-813 Original PDOException is dropped from... Resolved

 Description   

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

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

Message:

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



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

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

Comment by Marco Pivetta [ 23/Feb/14 ]

merged: https://github.com/doctrine/dbal/commit/646edacd87d5b9d201bf19aaf55ee0e4d5e470c2





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

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

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

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

 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





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

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

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

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

 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





[DBAL-820] [GH-531] Fix typo and formatting in security docs Created: 21/Feb/14  Updated: 21/Feb/14  Resolved: 21/Feb/14

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

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


 Description   

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

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

Message:



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/3c3a4b14bd9c98c2e27dc98613676442717891a1





[DBAL-819] Schema-tools does not work on multiple Oracle's schemas Created: 21/Feb/14  Updated: 22/Feb/14

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

Type: Bug Priority: Major
Reporter: Antoine Descamps Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, oracle, orm, schematool
Environment:

DB: Oracle 11g



 Description   

The schema-tools, used via the CLI, is not able to detect schema's changes when working on multiple schemas.

For instance, the ORM is configured with a "global" Oracle's user, having permissions on every schemas. To specify which entities belong to which schema, I've prefixed the table name with the corresponding schema.

When trying to do the following command:

orm:schema-tool:update --dump-sql

Doctrine returns me the following message:

Nothing to update - your database is already in sync with the current entity metadata.

If, instead of using the "global" user in the Doctrine's configuration, I set the user of the specific schema I'm trying to generate a table on based from an entity, it works.



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

Moved this to DBAL for now. It seems to be related to schema prefixed table names not being evaluated in the platforms when generating the SQL for reverse engineering the database schema.

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

Antoine Descamps Okay after having investigated on this in detail and thinking about the possibilities we have to find a solution for this, I came to the following conclusion:
ORM's schema tool and DBAL's schema introspection are designed to be bound to what Doctrine defines as "database" for each platform. This is the scope of the whole operation. In case of Oracle it is the "user". You cannot break out of this scope in any way as the current DBAL implementation is not designed for a "complete" schema introspection and therefore does not allow it at some points. Fully understanding your concern I am afraid we cannot find a reasonable solution for your use case at this point in development (2.x). Furthermore there is a good reason for limiting the schema introspection to a certain layer. If the schema tool would introspect the "complete" schema without regard to the database it is connected to, it would suggest a lot of schema changes from other databases that do not belong to the context of the entity manager / database. This behaviour would even cause a lot more annoyance to users as it is the default use case that users are only interested in one database per entity manager.
Also this problem is completely independant from your mapping definitions. So it doesn't matter whether you prefix your table names or not. When running the "update" operation on the schema tool, it is the online schema introspection part that is preventing the schema tool from behaving as you would wish.
Changing the schema introspection behaviour in DBAL would completely break BC and is at some places in the code not even possible without changing the API.
I am sorry that I have to disappoint you with this conclusion but we I am afraid we cannot do anything about your issue until we start developing 3.x. We might reevaluate your use case their and see what we can do.





[DBAL-818] Fetching identity value from an insert fails with merge replication enabled Created: 20/Feb/14  Updated: 20/Feb/14

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

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


 Description   

The way that the PDOSqlsrv driver fetches the identity value for a freshly inserted record will fail if there are triggers on a table that do a secondary insert on a table that also has an identity column.

This is the case when you set up merge replication in SQL Server. The replication creates a series of triggers on the tables to catch any of the changes made for the purposes of replication and inserts those changes elsewhere.

We have switched to using the native SQLSrv drivers instead to work around this since that uses "SELECT SCOPE_IDENTITY() AS LastInsertId" to fetch the value during the insert command.



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

I'm not quite sure whether we can fix this is in a reasonable way. See PDO's lastInsertId method in itself is documented to be very inconsistent and behaves differently throughout different drivers and even database versions.

This method may not return a meaningful or consistent result across different PDO drivers, because the underlying database may not even support the notion of auto-increment fields or sequences.

Because of this we do not have tests in our testsuite yet that cover the last insert id topic that work as expected on all drivers.
IIRC the fact that DBAL's implementation for the native sqlsrv driver uses "SELECT SCOPE_IDENTITY() AS LastInsertId" is a workaround to support this feature at all and come around the driver limitation IIRC. This as such is a dirty workaround and should IMO not be relied on for scenarios such as you describe.
I'm not quite sure what the expected behaviour of PDO drivers in general would be concerning triggers on PK columns that do other inserts regarding last insert IDs. IMO this is not a Doctrine bug but rather an unsupported use case or even a driver bug/limitation? Not sure on this.
The only thing we could actually do is implement the same workaround we have in the native sqlsrv driver for the PDO driver. But I would rather not do this for such an edge case scenarion.
But that's just my opinion

Comment by Michael Anthon [ 20/Feb/14 ]

Yes, I agree that any workaround will be a bit of a dirty hack.

The main problem is the PDO driver using @@identity to get the last inserted id, which is pretty much the wrong way to do it in all but the simplest of cases... SCOPE_IDENTITY is there for a reason but won't work when called subsequently since it's run inside an sp_prepexec and will be out of scope anyway (it has to be tacked onto the end of the insert statement as it is in the sqlsrv driver)

There's another piece of code in the SQLSrvConnection that uses this method...

 $sql = "SELECT IDENT_CURRENT(".$this->quote($name).") AS LastInsertId";

That could potentially be used as well and would probably give a more accurate answer but is also subject to race conditions on busy systems.





[DBAL-817] [GH-530] Skip empty config values Created: 19/Feb/14  Updated: 05/Mar/14  Resolved: 05/Mar/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 MaartenMortier:

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

Message:

We should skip empty values when building dsn, this allows us to define multiple config variables and keeping config template intact.



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

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





[DBAL-816] [GH-529] fix for postres listTableNames Created: 18/Feb/14  Updated: 18/Feb/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 MaksSlesarenko:

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

Message:

fix for listTableNames to return unescaped table names






[DBAL-815] Returning a wrong field type for Postgres Created: 18/Feb/14  Updated: 18/Feb/14  Resolved: 18/Feb/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: Odiel Leon Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-553 PostgreSQL JSON Type Resolved

 Description   

Trying to create a Postgres table widh a JSON field type I found a bug, the following code is not returning the right field type for this operation.

https://github.com/doctrine/dbal/blob/ca6a8dd20f3e8c1ad5fadaac8eac4547c081cf3b/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php#L864

It is returning TEXT instead of JSON.

Take in consideration that if a table was created before and an update is required in order to change the table structure errors will shown up, here an example.

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE mytable ALTER metadata TYPE JSON':

SQLSTATE[42804]: Datatype mismatch: 7 ERROR: column "metadata" cannot be cast automatically to type json
HINT: Specify a USING expression to perform the conversion.

[PDOException]
SQLSTATE[42804]: Datatype mismatch: 7 ERROR: column "metadata" cannot be cast automatically to type json
HINT: Specify a USING expression to perform the conversion.



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

Odiel Leon The JSON data type is only available in PostgreSQL version 9.2 and onwards. We added support for the native JSON data type in DBAL 2.5, which is not yet released. If you want to make use of the native JSON type you have to configure DBAL to use PostgreSQL92Platform.

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

Still for versions < 9.2 the TEXT type still should work. Unfortunately you did not provide enough information about what you are trying to achieve and in which context your mentioned errors occurr. But this is definitely not a bug in Doctrine.

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

Here is the PR where we implemented native JSON type support: https://github.com/doctrine/dbal/pull/469

Comment by Odiel Leon [ 18/Feb/14 ]

Yes sorry about that.

Basically I'm trying to create a JSON field type in a Postgres table, I'm using Postgres 9.3.

Trying to update my DB from the command line using Symfony2 commands, doctrine:update:schema, I always get a query updating the field to be TEXT, even if I force the command to run, it pops up again and again, not changing the field to be JSON type, here is the code for my entity:

<?php

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="mytable")
 */
class Mytable
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private $id;

	/**
	 * @var string
	 *
	 * @ORM\Column(name="signature", type="json_array")
	 */
	private $signature;

	/**
	 * @var int
	 *
	 * @ORM\Column(name="created_at", type="datetime")
	 */
	private $createdAt;


    /**
     * Get id
     *
	 * @codeCoverageIgnore
     * @return integer
     */
    public function getSignature()
    {
        return $this->id;
    }

	/**
	 * Sets the job id.
	 *
	 * @param $signature
	 * @return $this
	 */
	public function setSignature($signature)
    {
        $this->signature = $signature;

        return $this;
    }

	/**
	 * Sets the created at timestamp.
	 *
	 * @param int $timestamp
	 * @return $this
	 */
	public function setCreatedAt($timestamp)
	{
		$this->createdAt = $timestamp;

		return $this;
	}

	/**
	 * Returns the created at timestamp.
	 *
	 * @return int
	 */
	public function getCreatedAt()
	{
		return $this->createdAt;
	}

}
Comment by Steve Müller [ 18/Feb/14 ]

Yeah, as I said, native JSON types will be supported in DBAL 2.5. If you want to make immediate use of this, you have to upgrade your dependencies to use one of the Doctrine 2.5 beta versions or the current master. Also please note when doing this upgrade for DBAL only, this might break ORM compatibility unless you upgrade ORM to an according version, too.

Comment by Odiel Leon [ 18/Feb/14 ]

Ok, that sounds good, thanks for the explanation, would you be able to point me out a good ORM version compatible with it?

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

IMO you should use DBAL master and ORM master, which should be in sync at most. BUT!! We do not advice you to use it in production as we don't take responsibility for it being stable by now. ORM does not have a beta for 2.5 yet.





[DBAL-814] [GH-528] Applying patch suggested by @guilhermeblanco for SQLite's auto-inc integer PKs Created: 14/Feb/14  Updated: 14/Feb/14  Resolved: 14/Feb/14

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

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


 Description   

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

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

Message:

See symfony/symfony#10238

Ping @guilhermeblanco



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

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

Comment by Marco Pivetta [ 14/Feb/14 ]

https://github.com/doctrine/dbal/commit/da43b765e96ca8a80202fa5e2e67657e0ce61587





[DBAL-813] Original PDOException is dropped from previous property in wrapper Created: 14/Feb/14  Updated: 23/Feb/14  Resolved: 23/Feb/14

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

Type: Bug Priority: Major
Reporter: Filip Procházka Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Dependency
depends on DBAL-823 [GH-534] [DBAL-813] Original PDOExcep... Resolved

 Description   

https://github.com/doctrine/dbal/commit/262deeb122d4de1ad893c8a8c944b1c1926317cd#diff-276fe718ac0aa7fc20162d42ae4dc7b0R52

Is there any case when PDOException has it's own previous? I don't know of any. Even if it had one, it doesn't make sense because you're skipping one important!! piece in chain of exceptions that cause each other

Do you agree that the ->getPrevious() is wrong and should be removed? Should I send a pullrequest?



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

After having added the missing information from the wrapped \PDOException to Doctrine\DBAL\Driver\PDOException in commit:
https://github.com/doctrine/dbal/blob/b362492900bc59800441e0d9922736fc55bf8c41/lib/Doctrine/DBAL/Driver/PDOException.php#L54-L55
all information from \PDOException should be retrievable from the Doctrine\DBAL\Driver\PDOException wrapper now. Therefore there should be no change in behaviour in existing applications.
Filip Procházka Are you okay with the solution? Can this ticket be closed?

Comment by Filip Procházka [ 23/Feb/14 ]

I disagree, first of all you're dropping a stack trace of that exception and replacing it with other from higher level, it may not be all that important, but all best practises say that you should always pass the exception to `$previous`.

There is zero disadvantages when keeping the exception in the chain. The few kilobytes of memory saved means nothing in comparision to backwards compatibility (which was broken without any real benefit).

Comment by Marco Pivetta [ 23/Feb/14 ]

I agree that the original PDOException should be passed in as $previous, since PDOExceptions themselves may or may not have a non-null getPrevious() result.

Filip Procházka can you provide a pull request for that?

Comment by Filip Procházka [ 23/Feb/14 ]

Yes I can! There you go https://github.com/doctrine/dbal/pull/534 let me know if it needs any adjustments.

Comment by Doctrine Bot [ 23/Feb/14 ]

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

Comment by Marco Pivetta [ 23/Feb/14 ]

merged: https://github.com/doctrine/dbal/commit/646edacd87d5b9d201bf19aaf55ee0e4d5e470c2

Comment by Filip Procházka [ 23/Feb/14 ]

Thank you very much!





[DBAL-812] SchemaTool ignores multi-columns (composite) indexes when creating a foreign key Created: 13/Feb/14  Updated: 15/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Peter Huynh Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

MySQL



 Description   

When using the schema tool to generate the differences between the db and the entities, I notice the following:

ALTER TABLE sales ADD CONSTRAINT FK_36D222EF603EE73 FOREIGN KEY (vid) REFERENCES vendor (id);
CREATE INDEX IDX_36D222EF603EE73 ON sales (vid);

Normally, it doesn't bother me, however I have had an existing composite index consists of (vid, submit). This leads to the redundant index IDX_36D222EF603EE73 and therefore forcing unnecessary overheads.

It would be nice to have a mean to disable this from happening.

The code in question can be found at https://github.com/doctrine/dbal/blob/594e326bd58d1d7af578f0dc3143655b9d119d45/lib/Doctrine/DBAL/Schema/Table.php#L543.

A helpful member from #doctrine IRC also pointed out that it does not check the unique constraints also.

Regards,



 Comments   
Comment by Marco Pivetta [ 13/Feb/14 ]

Just a hint on this: looks like the current logic just checks hashed indexes, ignoring the "uniq" prefixed indexes to avoid duplicates.

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

Peter Huynh I get the point here. However after having a quick look into this it seems this behaviour exists for a good reason. See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Index.php#L191-L195
The question is how could this reasonable extended to fulfil the needs you explained. I am not entirely sure about this and this peace of code is rather sensitive and critical. I don't want to rush any assumptions here.

Comment by Peter Huynh [ 15/Feb/14 ]

Hi Steve,

I fully understand your reservation.

Thanks for looking into things.

Peter





[DBAL-811] [GH-527] Birko boolean conversion Created: 12/Feb/14  Updated: 12/Feb/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 birko:

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

Message:

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






[DBAL-810] [GH-526] Add close() method in MasterSlaveConnection.php Created: 11/Feb/14  Updated: 21/Feb/14  Resolved: 21/Feb/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 gohiei:

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

Message:

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

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



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/594e326bd58d1d7af578f0dc3143655b9d119d45





[DBAL-809] Decimal type: not convert to double variable type Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

Type: Bug Priority: Major
Reporter: Vitaliy Zhuk Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: None


 Description   

Hi.

The doctrine DBAL type "decimal" not convert value to "double" variable type in PHP. And if use events for control changes set, we have a changes for field.

For example:

/** Entity class **/
/** @ORM\Column(name="field", type="decimal")
private $field;

/** Create entity **/
$entity = new MyEntity();
$entity->setField(1);
$em->persist($entity);
$em->flush($entity);

/** Load entity **/
$entity = $em->field('MyEntity', 1);
var_dump($entity->getField()); // Then we have a string type
$entity->setField(1); // Set a integer type

Listener (onFlush):

$em = $event->getEntityManager();
$uow = $em->getUnitOfWork();

$entity = $event->getEntity();
$changes = $uow->getEntityChangeSet($entity);

var_dump($changes); // Changes exists, because variable type not equals

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/DecimalType.php#L52



 Comments   
Comment by Vitaliy Zhuk [ 09/Feb/14 ]

Sorry, i not seen the attention section in docs: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#decimal





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






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

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

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

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

 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





[DBAL-805] [GH-524] Added new test WriteTest::testEmptyIdentityInsert(). Created: 06/Feb/14  Updated: 06/Feb/14

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

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


 Description   

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

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

Message:

I added a missing test for AbstractPlatform::getEmptyIdentityInsertSQL().






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

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved 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-803] SQLSTATE[HY093]: Invalid parameter number: parameter was not defined Created: 06/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/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: Stefano Kowalke Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: mysql, querybuilder,
Environment:

OSX 10.8, PHP5.4, MySQL56


Issue Links:
Duplicate
duplicates DBAL-804 [GH-523] SQLSTATE[HY093]: Invalid par... Open

 Description   

This can be closed. I moved the description to http://www.doctrine-project.org/jira/browse/DBAL-804






[DBAL-802] Tablename quoting not working for ALTER TABLE Created: 06/Feb/14  Updated: 06/Feb/14

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

Type: Bug Priority: Major
Reporter: Dennis Birkholz Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: Quoting, TableDiff, mysql


 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.





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

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

Type: Improvement Priority: Minor
Reporter: gondo Assignee: Benjamin Eberlei
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.






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

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

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


 Description   

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

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

Message:

Added ORDER BY to doModifyLimitQuery in DB2Platform.php.






[DBAL-799] [GH-521] Fix Connection Interface Created: 29/Jan/14  Updated: 29/Jan/14  Resolved: 29/Jan/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: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-794 [GH-517] Fix method signature in Doct... Open

 Description   

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

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

Message:

PDOConnection passes a second variable into prepare.
The Interface should support it.



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

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





[DBAL-798] [GH-520] [WIP] Add pdo informix driver support Created: 28/Jan/14  Updated: 28/Jan/14

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

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


 Description   

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

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

Message:

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

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






[DBAL-797] [GH-519] Improve readability of EchoSQLLogger output format Created: 28/Jan/14  Updated: 28/Jan/14  Resolved: 28/Jan/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 sandvige:

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

Message:

When using EchoSQLLogger, the output format is a bit clumsy, and can be very hard to interpret. Here is just a fix to condensate a bit the output format when parameters and types are available.

Before:
```
array(4) {
[0] =>
array(1)

{ 'NaPingSchd' => int(2) }
[1] =>
int(60)
[2] =>
int(43200)
[3] =>
int(110)
}
array(4) { [0] => string(3) "map" [1] => string(7) "integer" [2] => string(7) "integer" [3] => string(7) "integer" }
```

After:
```
array(4) {
'map index: 0' =>
array(1) { 'NaPingSchd' => int(2) }

'integer index: 1' =>
int(60)
'integer index: 2' =>
int(43200)
'integer index: 3' =>
int(110)
}
```



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

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





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

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

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


 Description   

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

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

Message:

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






[DBAL-795] Error: "database schema is not in sync“ after Create/Update MyISAM tables Created: 11/Jan/14  Updated: 23/Feb/14  Resolved: 23/Feb/14

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

Type: Bug Priority: Minor
Reporter: Jacek Hensoldt Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

debian 6.0.3, MySQL 5.1.49, PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli)


Issue Links:
Reference
relates to DBAL-743 [GH-476] Fix foreign key propagation ... Resolved

 Description   

After create or update MyIsam tables: (doctrine orm:schema-tool:create doctrine orm:schema-tool:update --force)

When i check the schema with doctrine orm:validate-schema i get the error message:

doctrine orm:validate-schema
[Database] FAIL - The database schema is not in sync with the current mapping file.

The reason for this is, that Doctrine tries to add a foreign key contraint to myisam-table:

doctrine orm:schema-tool:update --dump-sql 

...
ALTER TABLE addresses ADD CONSTRAINT FK_6FCA7516A76ED395 FOREIGN KEY (user_id) REFERENCES users (id);


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

Jacek Hensoldt This issue should have been fixed in DBAL in commit: https://github.com/doctrine/dbal/commit/f99f6edde118dda70fe1c2c2f3dee31b6536a335
Can you please check if the problem still exists with the current master branch?

Comment by Jacek Hensoldt [ 12/Jan/14 ]

unfortunately it does not work

I have two tables with these definitions:

/**
 * @Entity @Table(name="addresses", options={"engine"="MyISAM"})
 **/

/**
 * @Entity @Table(name="users", options={"engine"="MyISAM"})
 **/

But aufter create I still get the same error message.

I inserted at line 661 this code:

//lib/Doctrine/DBAL/Platforms/MySqlPlatform.php

$hasOption = $diff->fromTable->hasOption('engine') ? 'YES' : 'NO';
echo "Engine hasOption?:".$hasOption;
echo "Engine: ".$engine;

Output:

Engine hasOption?:NO
Engine: INNODB

The hasOption()-check is working correctly, the problem is, that the engine-option is not set

$diff->fromTable->getOption('engine')

would throw an exception

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

Jacek Hensoldt Confirmed your issue. The problem is that custom table options like the table engine on MySQL don't get reverse engineered by Doctrine currently. Therefore the comparator recognizes differences between the online and offline table which in reality are not there.

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

Okay it's not a comparator issue as it currently does not compare table options at all. The comparator will detect foreign key changes because the online table does not have any foreign keys but your mapping propagates foreign keys through the relation. This cannot be detected in the comparator but has to be evaluated in the platform (which is already fixed). Then I guess the only issue is that the table does not get reverse engineered with the table options set.

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

This is tricky. We need to introspect the table options with the schema manager. Currently reverse engineering the online schema always results in table objects being created without table options. Therefore the comparator will always detect changes. We need to introduce something like AbstractSchemaManager::listTableOptions() and AbstractPlatform::getListTableOptionsSQL(). The latter could potentially be "empty" as currently only MySQL uses table options. Don't know what to do with those platforms. Throw "unsupported" exception? Return empty SQL? Both introduce problems in the schema manager. Throwing exception needs exception handling in the schema manager or another supports*() method in the AbstractPlatform to check against. Returning empty SQL is rather sloppy implementation and also needs handling in the schema manager.

Comment by Marco Pivetta [ 23/Feb/14 ]

After discussion with Steve Müller, I decided that this won't be fixed.

Numerous reasons behind this:

  • MyISAM is not really something we support, since the MySQL platform is built around InnoDB assumptions
  • This goes into specifics of your persistence layer, and it is not really required for the schema tools to support it
  • This will increase the workload for supporting exotic storage layers that we can't really maintain (it's like pandora's box)




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

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

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

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






[DBAL-793] [GH-516] The primary key columns don't have to be in the same order as the table columns Created: 17/Jan/14  Updated: 25/Mar/14  Resolved: 25/Mar/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 bartv2:

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

Message:

This happens when the columns are created in a different order then in the PK. This doesn't happen with Doctrine, as the order is taken from the PK.



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DBAL-792] [GH-515] Fix sqlite autoincrement detection Created: 17/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

When there are 2 PK-columns the code would still mark the first column as autoincrement.



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

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





[DBAL-791] [GH-514] [DBAL-789] Fix default values for TEXT/BLOB column type on MySQL Created: 16/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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 deeky666:

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

Message:

MySQL does not support default values for `TEXT` and `BLOB` type columns. This causes `CREATE TABLE` statements to fail if a default value is supplied for those column types:

```sql
Doctrine\DBAL\DBALException: An exception occurred while executing 'CREATE TABLE text_blob_default_value (def_text LONGTEXT DEFAULT 'def' NOT NULL, def_text_null LONGTEXT DEFAULT 'def', def_blob LONGBLOB DEFAULT 'def' NOT NULL, def_blob_null LONGBLOB DEFAULT 'def') DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB':

SQLSTATE[42000]: Syntax error or access violation: 1101 BLOB/TEXT column 'def_text' can't have a default value
```

Additionally useless `ALTER TABLE` statements are created for those mappings with the schema tool because online and offline schema differ for those column types concerning default values:

```sql
ALTER TABLE creative CHANGE filename filename LONGTEXT DEFAULT '' NOT NULL;
```



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

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





[DBAL-790] [GH-513] Add missing type hint Created: 16/Jan/14  Updated: 20/Jan/14  Resolved: 20/Jan/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 jfsimon:

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

Message:



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

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

Comment by Marco Pivetta [ 20/Jan/14 ]

The BC break introduced by this PR is not necessary and won't be fixed in 2.x





[DBAL-789] Default value not allowed on blob/text Created: 16/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

Type: Bug Priority: Major
Reporter: Klaus Jørgensen Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None
Environment:

LAMP



 Description   

introduced between v2.4.1 and v2.4.2

Doctrine is trying to set a default value on a LONGTEXT, it is not allowed in MySQL and ignored - resulting in an invalid schema and migration generating the same migration over and over again.

mysql> ALTER TABLE creative CHANGE filename filename LONGTEXT DEFAULT '' NOT NULL;
Query OK, 0 rows affected, 1 warning (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 1

mysql> show warnings;
-------------------------------------------------------------------

Level Code Message

-------------------------------------------------------------------

Warning 1101 BLOB/TEXT column 'filename' can't have a default value

-------------------------------------------------------------------
1 row in set (0.00 sec)



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

Thank you for reporting this issue. Patch supplied in PR: https://github.com/doctrine/dbal/pull/514

Comment by Doctrine Bot [ 08/Feb/14 ]

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





[DBAL-788] ORDER BY with function COUNT() fails Created: 08/Jan/14  Updated: 14/Mar/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: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

mssql 2008 R2



 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





[DBAL-787] [GH-512] Fix modifying limit/offset for statements with subqueries on SQL Server Created: 14/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

`SELECT` statements that contains subqueries in the `SELECT` clause do not get properly rewritten with a limit and/or offset applied to it resulting in wrong SQL.

*Example*
```sql
SELECT foo.id, (SELECT COUNT FROM bar) AS bar_count FROM foo
```

*Expected with a limit of 10*
```sql
SELECT * FROM (SELECT foo.id, (SELECT COUNT FROM bar) AS bar_count, ROW_NUMBER() OVER (ORDER BY (SELECT 0)) AS doctrine_rownum FROM foo) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10
```

*Actual with a limit of 10*
```sql
SELECT * FROM (SELECT foo.id, (SELECT COUNT, ROW_NUMBER() OVER (ORDER BY (SELECT 0)) AS doctrine_rownum FROM bar) AS bar_count FROM foo) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10
```

The `ROW_NUMBER() OVER` clause is misplaced into the subselect instead of into the main `FROM` clause.
What this PR does is recursively matching any (nested) parentheses inside the main `SELECT` clause to be able to identify the main `FROM` clause to add the `ROW_NUMBER() OVER` clause to.
This of course is far from perfect for matching all kinds of possible `SELECT` statement syntaxes but it fixes this particular issue, which is pretty common IMO.



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

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





[DBAL-786] [GH-511] Create the online table before listing it. Created: 14/Jan/14  Updated: 15/Jan/14  Resolved: 15/Jan/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 MMcM:

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

Message:

```phpunit --filter testDiffListTableColumns``` fails because the test is currently relying on another test to have created the list_table_columns table.

It also fails in our driver, which is now packaged separately and so runs a slightly different test order.

I assume that was not the intention when the test was created. So, this branch adds the CREATE TABLE.



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

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

Comment by Marco Pivetta [ 15/Jan/14 ]

Merged: https://github.com/doctrine/dbal/commit/0a7df7c58aeab4d1cef55a78e5ca50299a12a62b





[DBAL-785] [GH-510] Exclude HHVM + PostgreSQL build matrix on Travis for now Created: 14/Jan/14  Updated: 14/Jan/14  Resolved: 14/Jan/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 deeky666:

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

Message:

PR #498 introduced an extended build matrix for different PostgreSQL versions on Travis which should be excluded for HHVM as it does not currently support PostgreSQL.



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

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





[DBAL-784] [GH-509] Fix table lock hints on SQL Anywhere Created: 13/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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 deeky666:

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

Message:

`SQLAnywherePlatform::appendLockHint()` should not throw an exception if an unknown lock mode is given but rather return the unmodified `FROM` clause instead. This is especially required for ORM to work as it passes `null` by default which currently causes SQL Anywhere platform to throw an exception.



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

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





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

Issue Links:
Reference
relates to DDC-2310 Recent changes to DBAL SQL Server pla... Resolved

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 31/Jan/14 ]

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





[DBAL-782] [GH-507] Fix unique indexes in CREATE TABLE statements on SQL Anywhere Created: 13/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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 deeky666:

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

Message:

SQL Anywhere seems to distinguish between unique indexes and unique constraints. Unique constraints do not allow `NULL` values while unique indexes do.

A UNIQUE constraint is not the same as a unique index. Columns of a unique index are allowed to be NULL, while columns in a UNIQUE constraint are not. Also, a foreign key can reference either a primary key or a UNIQUE constraint, but cannot reference a unique index since a unique index can include multiple instances of NULL.

The current implementation create unique constraints instead of unique indexes during `CREATE TABLE` statements which causes ORM to fail as all nullable columns in a unique constraint silently get converted to `NOT NULL`.
This PR replace unique constraints by unique indexes in `CREATE TABLE`.



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

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





[DBAL-781] Doctrine maps tinyint with length > 1 to boolan Created: 10/Jan/14  Updated: 14/Jan/14  Resolved: 14/Jan/14

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

Type: Bug Priority: Minor
Reporter: Stefano Kowalke Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: boolean, dbal, mapping, tinyint
Environment:

OSX 10.8, PHP 5.4, MySQL 5.6



 Description   

Why Doctrine maps any tinyint, regardless its length to boolean type. According to the MySQL Documentation only tinyint(1) is equivalent to boolean. I searched the web and found only out that this is the way how Doctrine it does but not why, so I have to assume its a bug.

Hope someone who knows Doctrine better could enlighten me



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

Stefano Kowalke The length parameter for MySQL's integer does not have any effect unless you use it in conjunction with the ZEROFILL attribute. It does not have any meaning concerning min or max value and the storage requirements for that specific type but only specifies the display length for zerofill characters.

M indicates the maximum display width for integer types. For floating-point and fixed-point types, M is the total number of digits that can be stored. For string types, M is the maximum length. The maximum allowable value of M depends on the data type.

As MySQL does not have a native boolean type, Doctrine uses it to map it's own boolean type as it is the one that comes closest to a "boolean" type column. This is not a bug in Doctrine but an expected behaviour.
Hope I could clarify this.

Comment by Stefano Kowalke [ 11/Jan/14 ]

Hey Steve, thanks for your detailed informations. This helped me to understand the behavior and gave me a direction how to get more background informations.





[DBAL-780] [GH-506] [DBAL-752] Fix integer type declaration SQL on SQLite Created: 10/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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 deeky666:

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

Message:

This PR is complementary to https://github.com/doctrine/dbal/commit/6bd046d3bb1212bfd2808368a7143c9d95e3c157 and fixes also the type declaration SQL for integers on SQLite.



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

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





[DBAL-779] [GH-505] Add SMALLSERIAL type support on PostgreSQL 9.2 platform Created: 10/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Since PostgreSQL 9.2 there also is autoincrement support for `SMALLINT` type columns. The type to use is called `SMALLSERIAL`. This PR adds support for smallint autoincrement columns on `PostgreSQL92Platform`.
Please not that no further type mapping is necessarry, as `SMALLSERIAL` columns internally map to smallint in PostgreSQL which is already covered by `PostgreSQLPlatform`.



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

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





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

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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-777] [GH-503] Decode hex-encoded clobs/blobs when using pgsql on windows Created: 09/Jan/14  Updated: 09/Jan/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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





[DBAL-776] [GH-502] [DBAL-764] Document types / column usage properly Created: 09/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

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


 Description   

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

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

Message:

This PR massively improves the documentation of available DBAL types and also adds adds the documentation for the `Doctrine\DBAL\Schema\Column` class, its proper usage, capabilities and limitations concerning vendor support and portability.



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

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





[DBAL-775] [GH-501] Exclude HHVM + PostgreSQL and HHVM + Mysqli from travis build matrix Created: 08/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/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: 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/501

Message:

HHVM currently does not support `pdo_pgsql` and `mysqli` drivers and therefore it is useless to test those combinations in the Travis build matrix.



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

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





[DBAL-774] DBAL parses joins in wrong order Created: 08/Jan/14  Updated: 21/Mar/14

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

Type: Bug Priority: Critical
Reporter: Jeroen Thora Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: querybuilder


 Description   

I have a problem that doctrine dbal orders the joins in a wrong order if you use more complex join combinations (worked fine in DBAL 2.3)

Dbal Querybuilder:

        $qb->select('tbl_profile_additional_property.pkid AS pkid')
        ->from('tbl_profile_additional_property', 'tbl_profile_additional_property')
        ->leftjoin('tbl_profile_additional_property', 'tbl_rating_system', 'tbl_rating_system', 'tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid')
        ->leftjoin('tbl_rating_system', 'tbl_rating_system_translation', 'tbl_rating_system_translation', 'tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid')
        ->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')
        ->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')
        ->where('tbl_profile_additional_property.fk_function = :functionid')
        ->setParameter('functionid', $functionId)
        ->setParameter('languageid', $languageId);

Expected Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

Resulted Query:

SELECT 
tbl_profile_additional_property.pkid AS pkid 
FROM tbl_profile_additional_property tbl_profile_additional_property 
LEFT JOIN tbl_rating_system tbl_rating_system ON tbl_profile_additional_property.fk_rs = tbl_rating_system.pkid 
LEFT JOIN tbl_rating_system_translation tbl_rating_system_translation ON tbl_rating_system_translation.fk_rs = tbl_rating_system.pkid AND tbl_rating_system_translation.fk_language = :languageid 
LEFT JOIN tbl_score_level_translation tbl_score_level_translation ON tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid 
LEFT JOIN tbl_score_level tbl_score_level ON tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid 
WHERE tbl_profile_additional_property.fk_function = :functionid

(The last 2 LEFT JOINS of the query are the problem)

The problem is with getSQLForJoins it loops over all the joins and foreach join it follows all the used joins aliases until the deepest point. Therefor it will parse this join first

->leftjoin('tbl_rating_system_translation', 'tbl_score_level_translation', 'tbl_score_level_translation', 'tbl_score_level_translation.fk_rs_translation = tbl_rating_system_translation.pkid AND tbl_score_level_translation.fk_sl = tbl_score_level.pkid')

Before it generates the sql for this line (this line is needed becaus the line above needs a join on tbl_score_level first)

->leftjoin('tbl_profile_additional_property', 'tbl_score_level', 'tbl_score_level', 'tbl_profile_additional_property.fk_scoregoal = tbl_score_level.pkid')

The order the querybuilder in php is build (select, from, joins, etc) is the order it should be parsed as sql.

Ps. I have added 2.5 also as affectsversion because the code didn't change as far is i know



 Comments   
Comment by Chesley Brown [ 22/Jan/14 ]

Noticing this issue with v2.4 as well. However, I'm also noticing the leftJoins being ordered incorrectly on v2.3.3 as well... however the ordering between the two versions are not the same. They are both just ordered differently than the order that I actually call the leftJoin methods in.

Comment by Jeroen Thora [ 21/Mar/14 ]

I have added a failing test for this problem in doctrine/dbal#548





[DBAL-772] [GH-500] DBAL-761 - proposing a better exception message Created: 07/Jan/14  Updated: 09/Jan/14  Resolved: 09/Jan/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: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: DBAL-761


 Description   

This issue is created automatically through a Github pull request on behalf of dennis-fedco:

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

Message:

Suggestion to provide an exception message to aid in debugging certain type of issues (inaccessible tables). See http://www.doctrine-project.org/jira/browse/DBAL-761



 Comments   
Comment by Dennis Matveyev [ 07/Jan/14 ]

Created a pull request and oops didn't realize that it will create a JIRA issue. DBAL-761 already exists and has a much better description. Feel free to merge with GH-500 or remove this one... Thankx.

Comment by Doctrine Bot [ 08/Jan/14 ]

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

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

This is not the solution for the issue provided in the related JIRA ticket.





[DBAL-771] [GH-499] [DBAL-509] Quote identifiers in connection if necessary Created: 06/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/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: Invalid 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/499

Message:

Quotes identifiers in `Doctrine\DBAL\Connection` if necessary.



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

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





[DBAL-770] [GH-498] Add travis build matrix for all built-in PostgreSQL versions Created: 06/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/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 deeky666:

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

Message:

[Travis now ships with PostgreSQL version 9.1, 9.2 and 9.3 built-in](http://about.travis-ci.org/blog/2013-11-29-postgresql-92-93-now-available/). We should extend our build matrix to test on all versions.



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

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





[DBAL-769] [GH-497] Add dependency badge to the README Created: 06/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/14

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

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

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

Message:

I added version 2.4 to the README and added dependency badges. dev-master, 2.4 and 2.3 are up-to-date. Version 2.2 is outdated.



 Comments   
Comment by Robert Reiz [ 08/Jan/14 ]

Just updated the pull request on GitHub and details of this ticket.

Comment by Doctrine Bot [ 08/Jan/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/63ea7df5a5cec43f22b5cd4db9a347328f9d0c3b





[DBAL-768] [GH-496] Add missing type parameters to connection fetch methods Created: 05/Jan/14  Updated: 05/Jan/14  Resolved: 05/Jan/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

Issue Links:
Duplicate
duplicates DBAL-325 [GH-186] Added third an optional argu... Resolved

 Description   

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

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

Message:

Some `fetch*()` methods are missing the `$type` parameter in `Doctrine\DBAL\Connection`. This is a replacement for PR #186.



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/5b9e6a999727a46ba3b808dc0e1acce2e7713730





[DBAL-767] [GH-495] Fix DataAccess test on HHVM Created: 05/Jan/14  Updated: 08/Jan/14  Resolved: 08/Jan/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 deeky666:

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

Message:

HHVM expects constructor arguments to be `null` in `PDOStatement::setFetchMode()` when using `\PDO::FETCH_CLASS` with custom class that does not have a constructor.

```php
PDOException: SQLSTATE[HY000]: General error: user-supplied class does not have a constructor, use NULL for the ctor_params parameter, or simply omit it
```



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

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





[DBAL-766] PostgreSQL: Fix statement for getTableWhereClause method Created: 05/Jan/14  Updated: 17/Apr/14  Resolved: 05/Jan/14

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

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


 Description   

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






[DBAL-765] [GH-494] Refactor, consolidate and extend driver exception conversion Created: 05/Jan/14  Updated: 08/Feb/14  Resolved: 08/Feb/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 deeky666:

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

Message:

This PR aims to have are more solid, abstracted and flexible driver exception conversion API as introduced in PR #364.
It removes the `DBALExcpetion::ERROR_*` constants in favour of returning the appropriate DBAL driver exception directly in the driver. Those constants are of no meaning anymore, as these exceptions get converted into dedicated exception instances anyways. This also allows custom driver implementations to handle their driver exception conversion manually and introducing custom driver exception classes. Moreover it saves one additional conversion step in `DBALException`.
A new `DriverException` interface has been introduced for driver exception to return the error code, SQLSTATE and message. This is an approach to have a uniform driver API just like `Driver`, `Connection` and `Statement`. This also offers some other opportunities.
Complementary the `AbstractDriverException` and `PDOException` classes have been introduced to provide the basic implementation and behaviour for driver exceptions.
`PDOConnection` and `PDOStatement` now wrap all method calls into try catch blocks, catch `\PDOException` and wrap it into DBAL's `PDOException` to provide DBAL's `DriverException` interface.
The API of the `ExceptionConverterDriver` has been changed to take the DBAL generated exception message and a `DriverException` instance to evaluate the driver specific error code and SQLSTATE in order to return the appropriate standardized DBAL driver exception instance.
The following DBAL driver exception class changes have been made:

  • Introduce a base `DriverExcpetion` class for all DBAL driver exceptions.
  • Introduce a `ConnectionException` class for all errors related to connection attempts (an abstraction just like the vendors do)
  • Introduce a `ServerException` class for all error related to operations made on the server (after the connection has succeeded, an abstraction just like the vendors do)
  • Introduce a `DatabaseObjectNotFoundException` class as a base class for referenced database objects like schemas, table, constraints, indexes etc. that do not exists in the database (useful also for SQL Server which cannot distinguish between unknown tables, sequences, indexes etc.).
  • Introduce a `DatabaseObjectExistsException` class as a base class for referenced database objects like schemas, table, constraints, indexes etc. that do already exists in the database (useful also for SQL Server which cannot distinguish between already existing tables, sequences, indexes etc.).
  • Introduce a `ConstraintViolationException` class as a base class for all constraint violations like foreign key constraints, unique constraints, not null constraints, check constraints etc. (useful also if you only want to determine whether a data intergrity problem was found)
  • Remove `AccessDeniedException` in favour of `ConnectionException`. The term "access denied" should be reserved for insufficient privileges on a database operation IMO. This exception until now also refered to network errors, unknown hosts etc. errors during a connection attempt. So IMO the term is misleading and should be changed to a more general connection error exception.
  • Rename `NotNullableException` to `NotNullConstraintViolationException` as it is a constraint in general and should also be named as such.
  • Renamed `DuplicateKeyException` to `UniqueConstraintViolationException` as it is a constraint and should also be named as such.
  • Removed `FailedToOpenException` and mapped it to `ConnectionException` as it is a SQLite specific exception and should be treated in a more general/abstracted sense.
  • Map `ReadOnlyException` to `ServerException` as it can only occurr if the connection has been established already. It was a connection error before.

There are a lot of changes that have been made but I think they are reasonable and important to have a better abstracted exception API. Also I would like to introduce a `Configuration` option for custom driver exception conversion which is only possible with this approach.

I hope you will like it, otherwise blame me to death!



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

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





[DBAL-764] Provide a reference of the portable Column types and options Created: 04/Jan/14  Updated: 15/Feb/14  Resolved: 15/Feb/14

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

Type: Documentation Priority: Minor
Reporter: Frederic G. MARAND Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: Cli, documentation

Attachments: File SchemaReferenceCommand.php    

 Description   

One difficulty I had with the existing documentation and tools for DBAL was the lack of a reference for what the valid values were (e.g. "notnull" instead of "not null").

See http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html for example: some values are given, but there is no reference list, and anything put just in documentation would incur the risk of not remaining updated.

So I tried to guess-generate the information from the code, like this: https://gist.github.com/FGM/8261606 (also attached).

Unless an equivalent already exists somewhere, I think it could be useful to have something like this in upcoming releases.



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

Documentation supplied in PR: https://github.com/doctrine/dbal/pull/502
Please give a shout if something is missing, wrong, arguable or what...

Comment by Frederic G. MARAND [ 09/Jan/14 ]

Glad to see so much information in your PR. Did you create it from scratch or was it available elsewhere ?

Also, since the project seems to have some difficulty keeping up with "guide"-type documentation vs code evolutions, wouldn't it be feasible to have most of this information be generated from code (or phpdoc), to have it be automatically maintained when code changes ?

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

Frederic G. MARAND I created it from scratch as you requested in this ticket. We are aware the DBAL documentation isn't in the best shape, but we are working on it step by step. Please bare with us if it takes some time to catch up all the missing things.
An API documentation is always autogenerated and published automatically on the Doctrine website: http://www.doctrine-project.org/api/dbal/2.4/index.html

Comment by Frederic G. MARAND [ 09/Jan/14 ]

OK, i was afraid it was somewhere and I had missed it. Beyond that, don't you think it would be a good idea to have such lists of information be maintained as phpdoc rather than in the doc sources, and exported instead of being types. This would allow such commands as the one I had imagined (obviously better done).

Comment by Doctrine Bot [ 08/Feb/14 ]

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/6adc9ee1cb51e4ffef9811cf1d63de152824dd0d





[DBAL-763] [GH-493] Unit Test for getTableWhereClause method Created: 04/Jan/14  Updated: 05/Jan/14  Resolved: 05/Jan/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:
Duplicate
duplicates DBAL-733 [GH-466] Error on PostgreSQL 9.3 REVE... Resolved

 Description   

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

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

Message:

Unit Test for the commit #492 [Fix statement for getTableWhereClause method](
https://github.com/doctrine/dbal/pull/492)



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

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

Comment by Doctrine Bot [ 05/Jan/14 ]

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

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

The unit test contained errors and was incomplete. It could not be done this way.





[DBAL-762] [GH-491] Fix SQL Server drivers functional test suite and drivers Created: 04/Jan/14  Updated: 05/Jan/14  Resolved: 05/Jan/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 deeky666:

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

Message:

This should finally fix the functional test suites for SQL Server's `sqlsrv` and `pdo_sqlsrv` drivers. It introduces the following changes:

Please also note that the functional test suite will still fail if the underlying SQL Server database does not support SQL Azure as there currently is no reasonable way to distinguish those tests from SQL Server. Otherwise the tests now all pass!



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

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





[DBAL-761] Driver\ResultStatement::fetchAll() returns empty array on a seemingly valid Driver\PDOStatement object Created: 03/Jan/14  Updated: 08/Jan/14

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

Type: Improvement Priority: Minor
Reporter: Dennis Matveyev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, orm, query, schematool
Environment:

Windows 7 64 bit, Zend Server/Studio, PHP 5.4.16,
Server: Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8x



 Description   

I came across a weird issue, where when running:

vendor/bin/doctrine-module orm:schema-tool:update

I would get:

[Doctrine\DBAL\Schema\SchemaException]
There is no column with name 'resource_id' on table 'role_resource'.

But I did have a column with the above name in the above table, so that was a weird message for me. So I traced it all the way to this line of code:

https://github.com/doctrine/dbal/blob/2.4/lib/Doctrine/DBAL/Connection.php#L630

If I remove "->fetchAll()" from that line, I get this object:

object(Doctrine\DBAL\Driver\PDOStatement)#531 (1)

{ ["queryString"]=> string(332) "SELECT COLUMN_NAME AS Field, COLUMN_TYPE AS Type, IS_NULLABLE AS `Null`, COLUMN_KEY AS `Key`, COLUMN_DEFAULT AS `Default`, EXTRA AS Extra, COLUMN_COMMENT AS Comment, CHARACTER_SET_NAME AS CharacterSet, COLLATION_NAME AS CollactionName FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'loginauth' AND TABLE_NAME = 'role_resource'" }

Which has a valid SQL query that runs fine and shows Field names on my local machine's MySQL prompt. But when I add ->fetchAll() back in that line of code, an empty array is returned, field names are not returned, and a SchemaException is generated. I found this odd and wanted to report it. Whether it is a bug or not, hopefully I can find the cause of this issue.

For loads more info, please see this: http://stackoverflow.com/questions/20907491/doctrine-2-there-is-no-column-with-name-columnname-on-table-table



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

Dennis Matveyev It seems you are using MySQL. Can you please tell which version you use?

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

Dennis Matveyev Please also provide whether you use mysqli or PDO_MYSQL.

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

Dennis Matveyev Sounds dumb, but also are you sure that the vendor/bin/doctrine-module orm:schema-tool:update uses the correct connection parameters and does not by error connect to another database server or something? Because otherwise everything looks good IMO.

Comment by Dennis Matveyev [ 07/Jan/14 ]

Yes, I am using:
Server version: 5.5.23-log MySQL Community Server (GPL)
mysql client Ver 14.14 Distrib 5.5.23, for Win32 (x86)

Doctrine connection string for 'driverClass' is 'Doctrine\DBAL\Driver\PDOMySql\Driver', so it is PDO_MYSQL.

I am connecting to the right database, but your last suggestion is what helped to uncover the issue. When connecting to the database with the very same user/pass, and running the command, here is what I saw:

mysql> select resource_id from role_resource;
ERROR 1142 (42000): SELECT command denied to user 'login'@'localhost' for table 'role_resource'

Running a GRANT command to allow SELECT for this user solved the problem.

To improve debugging of similar issues, I'd see if there is a way to propagate the error from MySQL server to ./doctrine-module,
or
improve the error message of SchemaException, to i.e. "There is no column with name 'action_id' on table 'role_action', or database permissions prevent table access."

Thanks!

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

Dennis Matveyev Thank you for reporting this and I'm glad I could help. I will mark this as improvement, though. You are right in that the root cause of the error should be propagated to the user instead.

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

Dennis Matveyev Okay I found the root cause of the problem. See what MySQL states about access to the information_schema table for retrieving metadata about a certain database:

Each MySQL user has the right to access these tables, but can see only the rows in the tables that correspond to objects for which the user has the proper access privileges. In some cases (for example, the ROUTINE_DEFINITION column in the INFORMATION_SCHEMA.ROUTINES table), users who have insufficient privileges will see NULL.

So it returns NULL instead of raising an error and this is why Doctrine is not able to propagate the proper exception in this case. I'm not sure if changing the exception message in the SchemaException class is the proper way of handling this. Also please note that this is not only about columns (where you got stuck at) but can occurr for almost every list*() action called in the SchemaManager I suppose. Furthermore this might be a MySQL specific issue, not sure about that.

The proper solution would be to throw an exception much earlier, to have a decent behaviour in such an edge case. I think we should throw an exception here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L267 because a table cannot live without columns and indicates an error somewhere. But I would like to hear the opinion of Benjamin Eberlei on that issue.

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

I checked the SQL Server documentation and it seems they behave exactly the same: http://technet.microsoft.com/en-us/library/ms187113.aspx

In SQL Server 2005 and later, the visibility of metadata is limited to securables that a user either owns or on which the user has been granted some permission. For example, the following query returns a row if the user has been granted a permission such as SELECT or INSERT on the table myTable.

However, if the user does not have any permission on myTable, the query returns an empty result set.





[DBAL-760] [GH-490] Don't return warnings as errors in sqlsrv driver Created: 03/Jan/14  Updated: 17/Apr/14  Resolved: 03/Jan/14

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

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


 Description   

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

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

Message:

The SQL Server platforms use `sp_rename` stored procedure for renaming schema objects like tables, indexes or columns. SQL Server raises a warning when invoking this stored procedure, although the result is as expected:

```php
Doctrine\DBAL\Driver\SQLSrv\SQLSrvException: SQLSTATE [01000, 15477]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Vorsicht: Wenn Sie Teile eines Objektnamens ��ndern, werden Skripts und gespeicherte Prozeduren m��glicherweise funktionsunf��hig.
```

This PR configures the sqlsrv driver not to handle warnings returned from the server as errors to prevent this. The PDO_SQLSRV driver silences warnings, too.



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

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





[DBAL-759] [GH-489] Fix driver error while introspecting sequences in SQL Server 2012 Created: 02/Jan/14  Updated: 03/Jan/14  Resolved: 03/Jan/14

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

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


 Description   

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

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

Message:

It seems the SQL Server drivers don't like SQL Server's special `sql_variant` data type when retrieving data from such columns. Therefore introspecting Sequences in SQL Server 2012 generates the following error:

```php
Fatal error: Unexpected SQL type encountered in calc_string_size. in C:\cygwin\home\Administrator\dev\dbal\lib\Doctrine\DBAL\Driver\SQLSrv\SQLSrvStatement.php on line 226
```

A workaround this limitation is to cast the specific columns to `VARCHAR` in the query.



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

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





[DBAL-758] [GH-488] Fix integer type mapping in SQL Anywhere 16 Created: 02/Jan/14  Updated: 03/Jan/14  Resolved: 03/Jan/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 deeky666:

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

Message:

SQL Anywhere 16 seems to have changed the return value of integer type columns from `int` to `integer` when introspecting table columns. This causes the functional test suite to fail.



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

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





[DBAL-757] Add automatic platform version detection Created: 02/Jan/14  Updated: 16/Feb/14  Resolved: 16/Feb/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: 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/487

Message:

As more and more vendor version specific platforms evolve, it is time to make an approach of autodetecting and using the correct platform on connection. This is done by introducing two new interfaces `Doctrine\DBAL\VersionAwarePlatformDriver` and `Doctrine\DBAL\Driver\ServerInfoAwareConnection` which are implemented by Doctrine's driver and driver connection classes. They are introduced to keep BC for custom driver / driver connection classes.
`VersionAwarePlatformDriver::createDatabasePlatformForVersion($version)` is responsible for evaluating a given vendor specific version number and instantiating the correct platform for it. The current implementations normalize the given version string and use `version_compare()` for evaluation.
`ServerInfoAwareConnection::getServerVersion()` is responsible for returning the normalized version string of the database server currently connected to. `ServerInfoAwareConnection::requiresQueryForServerVersion()` defines whether receiving that information requires an additional database query or not which is important for `Doctrine\DBAL\Connection` as described in the following.
`Doctrine\DBAL\Connection` now takes an additional (optional) connection parameter `serverVersion` which the user can pass to skip platform autodetection and define the desired platform version straight away. This is also required for drivers that cannot return the database server version without an additional query (performance reasons). Platform version detection is now done in the following order of precedence:

1. Evaluate `platform` connection parameter and return an instance of that class if given.
2. Evaluate if the underlying driver is capable of creating platform instances by version. If not, return the default platform instance that would be returned by the current implementation.
3. Evaluate if `serverVersion` connection parameter is given and return the appropriate platform instance for that version.
4. Evaluate if the underlying driver connection can return the server version and can return it without the need of an additional query -> return the appropriate platform instance for that version.
5. Otherwise return the default platform instance that would be returned by the current implementation.

As a positive side effect while implementing the new interfaces, the driver classes were refactored by extracting abstract base driver classes for each vendor. This removes a lot of duplicated code in the driver classes that are related to the same database vendor. Please also note, that `DrizzlePDOMySql` now directly inherits from `Doctrine\DBAL\Driver\PDOMySql\Driver` to come around additional code duplication.

The only BC break introduced by this PR should be the visibility change of `Doctrine\DBAL\Connection::$_platform` from protected to private (as wished by @beberlei).
The only drawback of this implementation is that `Doctrine\DBAL\Connection::getDatabasePlatform()` now needs to do the real connect (if uninitialized) under some circumstances when it needs to autodetect the server version from the driver connection. Therefore I had to change the initialization of temporary connections in the functional test suite a little bit, so that calling `Doctrine\DBAL\Connection::getDatabasePlatform()` does not raise an error if the supplied temporary database does not exist. I think this is acceptable as it is not necessary to connect to a specific database anyways when only needing to drop and create the real test database.

As soon as the doctrine team agrees on this approach, I will add some more test and documentation for this. Until then this is a WIP PR.



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

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





[DBAL-756] Allow platforms to return the vendor instead of version specific names as well Created: 01/Jan/14  Updated: 01/Jan/14  Resolved: 01/Jan/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

New method `getVendor` required.






[DBAL-755] [GH-486] Add mysqli data seek support Created: 31/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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


 Description   

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

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

Message:

http://php.net/manual/en/mysqli-result.data-seek.php
Usefull to reset results cursor after fetch one result



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

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





[DBAL-754] [GH-485] 2.4 Add mysqli data seek support Created: 31/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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


 Description   

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

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

Message:

http://php.net/manual/en/mysqli-result.data-seek.php
Usefull to reset results cursor after fetch one result



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

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





[DBAL-753] Evaluate owncloud patch for Oracle quoting Created: 31/Dec/13  Updated: 01/Jan/14

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

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


 Description   

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



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

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





[DBAL-752] Fix handling of unsigned integers on Sqlite Created: 31/Dec/13  Updated: 31/Dec/13  Resolved: 31/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Benjamin Eberlei [ 31/Dec/13 ]

See https://github.com/doctrine/dbal/commit/6bd046d3bb1212bfd2808368a7143c9d95e3c157





[DBAL-751] [GH-484] Implement ExceptionConverterDriver in Oracle drivers Created: 30/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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


 Description   

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

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

Message:

Complementary to PR https://github.com/doctrine/dbal/pull/364.



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

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





[DBAL-750] [GH-483] Fix parsing SQL Server bracket delimiters in SQL statements Created: 30/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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


 Description   

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

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

Message:

Currently `SQLParserUtils` does not take SQL Server's bracket identifier delimiters into account when parsing parameter placeholders. Colons and question marks should not be considered as parameter placeholder in explicitly quoted identifiers (as is the case already for single quoted, double quoted and backtick quoted identifiers).

*Example*
```sql
SELECT [column?], [ns::column], [column], foo, ? FROM bar
```
The `SQLParserUtil` should detect exactly one placeholder here.



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

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





[DBAL-749] [GH-482] Fix some assertion and CS in schema manager functional tests Created: 30/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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


 Description   

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

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

Message:

See discussion in PR https://github.com/doctrine/dbal/pull/481



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

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





[DBAL-748] [GH-481] Fix Oracle test suite Created: 29/Dec/13  Updated: 30/Dec/13  Resolved: 30/Dec/13

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

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


 Description   

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

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

Message:

Final fixes for the Oracle test suite to run again without errors:

```bash
deeky@98N-MUELLER-STEVE:~/dev/doctrine/dbal$ phpunit -c oci8.phpunit.xml
PHPUnit 3.7.27 by Sebastian Bergmann.

Configuration read from /home/deeky/dev/doctrine/dbal/oci8.phpunit.xml

..........................................................SSS 61 / 1578 ( 3%)
S.............................S.SS...SSSSSSSSSSSSSS.S.SSSSS.. 122 / 1578 ( 7%)
..SSS.....................SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 183 / 1578 ( 11%)
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS..........S.......S 244 / 1578 ( 15%)
......SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 305 / 1578 ( 19%)
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS 366 / 1578 ( 23%)
S..SSS..SS.S.........................S....................... 427 / 1578 ( 27%)
............................................................. 488 / 1578 ( 30%)
............................................................. 549 / 1578 ( 34%)
............................................................. 610 / 1578 ( 38%)
...........................................................S. 671 / 1578 ( 42%)
............................................................. 732 / 1578 ( 46%)
.....................................S......S................ 793 / 1578 ( 50%)
............................................................. 854 / 1578 ( 54%)
......................S.....S................................ 915 / 1578 ( 57%)
............................................................. 976 / 1578 ( 61%)
............................................................. 1037 / 1578 ( 65%)
............................................................. 1098 / 1578 ( 69%)
.......................................................SSS... 1159 / 1578 ( 73%)
............................................................. 1220 / 1578 ( 77%)
............................................................. 1281 / 1578 ( 81%)
............................................................. 1342 / 1578 ( 85%)
................S............................................ 1403 / 1578 ( 88%)
............................................................. 1464 / 1578 ( 92%)
.....S..SSS.................................................. 1525 / 1578 ( 96%)
.....................................................

Time: 2.19 minutes, Memory: 50.25Mb

OK, but incomplete or skipped tests!
Tests: 1578, Assertions: 2852, Skipped: 246.
```

*Changes*

  • Skip tests for unsupported rollback of DDL statements during transactions

And finally... HALLELUJAH! :+1:

  • Fix default NULL value (again) containing trailing whitespace when retrieved from database
  • Fix drop and create database test by utilizing temporary connection in favour of real connection which has sufficient privileges and changing database name to match Oracle 12c requirements


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

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





[DBAL-747] [GH-480] [DBAL-558] Fix parsing parameters in quoted text with backslash Created: 29/Dec/13  Updated: 29/Dec/13  Resolved: 29/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


 Description   

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

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

Message:

Parsing SQL statements that contain single backslashes in quoted text breaks retrieving unquoted statement fragments.

*Example*
```sql
SELECT * FROM foo WHERE bar = 'Doctrine\DBAL\SQLParserUtils'
```



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

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





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

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

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


 Description   

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

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

Message:

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






[DBAL-745] [GH-478] Add missing driver exception subclasses Created: 29/Dec/13  Updated: 30/Dec/13  Resolved: 30/Dec/13

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

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


 Description   

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

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

Message:

Complementary to https://github.com/doctrine/dbal/pull/458/files



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

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





[DBAL-744] [GH-477] [DBAL-552] Fix parsing backtick quoted statement fragments in SQLParserUtils Created: 29/Dec/13  Updated: 17/Apr/14  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

MySQL uses backtick for identifier quotation. The `SQLParserUtils` treats statements with quoted identifiers that contain a colon as named parameter which is wrong.

*Example*
```sql
SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1
```

*Throws exception*
```
An exception occurred while executing 'SELECT `d.ns:col_name` FROM my_table d WHERE `d.date` >= :param1' with params ["2013-06-24 14:22:18"]: Value for :col_name not found in params array. Params array key should be "col_name"
```

This PR adds the backtick character to the recognized quote characters when retrieving unquoted statement fragments.



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

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





[DBAL-743] [GH-476] Fix foreign key propagation on non-supporting MySQL table engines Created: 28/Dec/13  Updated: 11/Jan/14  Resolved: 29/Dec/13

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

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

Issue Links:
Reference
is referenced by DBAL-795 Error: "database schema is not in syn... Resolved

 Description   

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

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

Message:

`CREATE TABLE` and `ALTER TABLE` statements on MySQL should not propagate foreign key constraint creation/alteration on non-supporting table engines. This is a fix for a migrations issue discussed in https://github.com/doctrine/migrations/issues/43.






[DBAL-742] [GH-475] Fix column default value introspection in Oracle Created: 28/Dec/13  Updated: 17/Apr/14  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

A bug in `OracleSchemaManager` cause a column's default value always to be null. Besides that default values are enclosed in single quotes when retrieved from database which is not evaluated by the schema manager, either.
This PR also fixes the default value tests in Oracle's functional test suite.



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

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





[DBAL-741] [GH-474] Fix foreign key columns order in Oracle Created: 28/Dec/13  Updated: 17/Apr/14  Resolved: 29/Dec/13

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

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

Message:

The order of columns in foreign key constraints is not synchronized by the Oracle platform.

*Failing test:*
```bash
Doctrine\Tests\DBAL\Functional\Schema\OracleSchemaManagerTest::testListForeignKeysComposite
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array (

  • 0 => 'id'
  • 1 => 'foreign_key_test'
    + 0 => 'foreign_key_test'
    + 1 => 'id'
    )

/home/deeky/dev/doctrine/dbal/tests/Doctrine/Tests/DBAL/Functional/Schema/SchemaManagerFunctionalTestCase.php:672
```



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

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





[DBAL-740] [GH-473] [DBAL-234] Add support for renaming indexes Created: 28/Dec/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

Currently renamed only indexes are scheduled for removal and recreation in the comparator. However recreating an index when only the name has changed is very inefficient on large tables as it internally requires a table recreation on most of the platforms. Many vendors offer a more efficient syntax for renaming indexes which saves the table recreation. This PR introduces this behaviour on capable platforms. Platforms that do not support this kind of syntax still use the current behaviour of dropping and recreating an index.
This PR also introduces the `Table::renameIndex()` method and the `MySQL57Platform` platform which adds [support for explicitly renaming indexes](http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html).



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

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

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

Fixed in commit: https://github.com/doctrine/dbal/commit/6d0e8e2a8598f121cdb136507022915247fc98b8





[DBAL-739] [GH-472] Fix index flags Created: 28/Dec/13  Updated: 28/Dec/13  Resolved: 28/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: 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/472

Message:

`Index` does not consistently use the defined property `$_flags` throughout the flag methods. Therefore `Index::getFlags()` does not return the defined flags.



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

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

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

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





[DBAL-738] [GH-471] [DBAL-685] Add servicename connection parameter to Oracle drivers Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

Currently Doctrine's Oracle drivers do not distinguish between `SID` / `SERVICE_NAME` and `DBNAME` connection parameters which do not necessarily have to be the same in every database environment setup. The `SID` is the unique name of the database instance to connect to and can be superseded by a more general `SERVICE_NAME` which can be configured to contain multiple database instances in a HA environment on server side. For each individual database environment setup to work we need to be able to specify different values for `SID` / `SERVICE_NAME` and `DBNAME`.
This PR adds an additonal `servicename` connection parameter which is used instead of `dbname` for the `SID` / `SERVICE_NAME` connection parameters *IF* given. I also updated the docs to cover this and another parameter `service` which was introduced in DBAL-141(http://www.doctrine-project.org/jira/browse/DBAL-141) but never got documented.






[DBAL-737] [GH-470] Connection: Replaced ! is_int with is_string Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

Intended side effect is not to call extractTypeValues when $types array is empty which it is by default.

It should be clear from commit.

`! is_int(key([])` => `true`
`is_string(key[])` => `false`



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

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





[DBAL-736] [GH-469] [DBAL-553] Add support for native JSON type on capable platforms Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

PostgreSQL introduced a native JSON type in version 9.2. This PR adds support for native JSON type declarations on capable platforms (currently only PostgreSQL). The implementation is adopted form the native GUID type support.



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

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





[DBAL-735] [GH-468] Fix dropping table without autoincrement trigger in Oracle Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

Autoincrement primary key columns are implemented as a triggers that emulate autoincrementation in Oracle. Dropping tables with Oracle's schema manager first drops those triggers before actually dropping the table. However when there is no such trigger (either if the primary key was not defined as autoincrement column or the trigger could not be found on database side) dropping the table via schema manager fails silently and the table still exists. Dropping those triggers should not cause the schema manager to skip executing the `DROP TABLE` statement. Therefore this PR wraps dropping the trigger into a `tryMethod()` so that it can fail and still call the actual `dropTable` operation.
This also fixes a lot of failing functional tests in Oracle's test suite where tables without autoincrement primary keys column are created and dropped.



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

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





[DBAL-734] [GH-467] [DBAL-472] Fix altering column from notnull to null in Oracle Created: 27/Dec/13  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

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


 Description   

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

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

Message:

Oracle requires an explicit `NULL` clause when altering a column from `NOT NULL` to `NULL`. Otherwise the existing notnull constraint remains unchanged.
This PR changes Oracles column declaration SQL snippet to always specify `NULL` and `NOT NULL` in `CREATE TABLE` and `ALTER TABLE` statements. This is a perfectly valid syntax and also functional tested.



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

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





[DBAL-733] [GH-466] Error on PostgreSQL 9.3 REVERSE ENGINEERING tables Created: 27/Dec/13  Updated: 05/Jan/14  Resolved: 05/Jan/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: Invalid Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-763 [GH-493] Unit Test for getTableWhereC... Resolved

 Description   

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

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

Message:

"Table xxxxx_xxxxx has no primary key. Doctrine does not support reverse engineering from tables that don't have a primary key."

This table was on PUBLIC schema and with a PK composed by 3 fields.



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

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

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

The provided fix is invalid and caught by PR:
https://github.com/doctrine/dbal/pull/492

Comment by Doctrine Bot [ 05/Jan/14 ]

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





[DBAL-732] MySQL 5.6 - Cannot change column 'fkProjectId': used in a foreign key constraint Created: 24/Dec/13  Updated: 18/Mar/14

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

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

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

 Description   

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

Generated SQL

ALTER TABLE badges CHANGE fkProjectId fkProjectId INT NOT NULL

Result in the following error

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

More info:

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

Original issue:



 Comments   
Comment by