[DBAL-1210] [GH-842] Fixed incorrect handling of single quotes in SQL-Strings Created: 26/Apr/15  Updated: 26/Apr/15

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 ancpru:

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

Message:

escaped by repeated single-quote (DBAL-1205)






[DBAL-1209] [GH-841] Documentation & code styling fixes Created: 25/Apr/15  Updated: 25/Apr/15

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/841

Message:

This fixes:

  • incorrect / incomplete / missing PHPdoc
  • wrong case for method names
  • unused imports





[DBAL-1208] [GH-840] Driver for SQLite3 Created: 25/Apr/15  Updated: 25/Apr/15

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/840

Message:

This PR adds an additional driver using the [SQLite3](http://php.net/manual/fr/book.sqlite3.php) class, in addition to the PDO_SQLITE driver.

    1. Why this driver?

Even though the PDO SQLite driver is already available to interact with SQLite databases, PDO currently has a big limitation: it [does not allow to load SQLite extensions](https://bugs.php.net/bug.php?id=64810).

This functionality is provided by the `SQLite3` class, which becomes your only option if you need to use your PHP application with an SQLite extension such as [SpatiaLite](http://www.gaia-gis.it/gaia-sins/).






[DBAL-1207] Schema Update Issue with DBAL 2.5 Binary Type Created: 24/Apr/15  Updated: 24/Apr/15

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

Type: Bug Priority: Major
Reporter: Alex Gurrola Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Ubuntu 14.04.2 LTS, Apache 2.4.7, PHP 2.5.9, MySQL 5.5, Symfony 2.6.6



 Description   

Every time I run a doctrine:schema:update command within Symfony, using DBAL 2.5, it tries to execute this SQL Query, every single time:

SQL Query
ALTER TABLE user_sessions CHANGE sess_id sess_id VARBINARY(128) NOT NULL;

The PHP Annotations I am using for this column is as follows:

Binary Column
/**
 * @var string
 *
 * @ORM\Column(name="sess_id", type="binary", length=128, nullable=false)
 * @ORM\Id
 * @ORM\GeneratedValue(strategy="IDENTITY")
 */
private $sessId;

It seems the binary type is somehow registering a change even though no change has actually been made. I updated to DBAL to 2.5 before getting the binary type supported by the doctrine:schema:update command.

Thanks in advance for any assistance in squashing this odd bug.

--Alex Gurrola






[DBAL-1206] Generating Table SQL without indexes is invalid if using AUTO_INCREMENT Created: 24/Apr/15  Updated: 24/Apr/15

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

Type: Bug Priority: Minor
Reporter: Markus Fasselt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL (but maybe other database vendors too)



 Description   

Dumping the following table

CREATE TABLE `users` (
    `id` INT AUTO_INCREMENT NOT NULL,
    PRIMARY KEY (`id`)
);

with the following snippet (0 = NoIndexes)

$platform->getCreateTableSQL($table, 0);

results in


CREATE TABLE `users` (
    `id` INT AUTO_INCREMENT NOT NULL,
);

The problem is, that the table contains an AUTO_INCREMENT column which cannot be used without a primary key. But the primary key is skipped, as I skipped all indexes.

As this SQL is invalid, I suggest to skip the AUTO_INCREMENT argument, too, if the indexes are skipped. Alternatively, the Primary Key always has to be included.

What do you think? I can provide a fix, if you agree with me.






[DBAL-1205] getPlaceholderPositions finds placeholders which are actually no placeholder if string contains single quotes Created: 24/Apr/15  Updated: 24/Apr/15

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

Type: Bug Priority: Critical
Reporter: Andreas Prucha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The following statement obviously does not contain any parameters:

select
'quoted1 '' :not_a_param1 quoted2 "'':not_a_param2''" ''' foo
from rdb$database

But the following call:

$params = \Doctrine\DBAL\SQLParserUtils::getPlaceholderPositions
('select \'quoted1 \'\' :not_a_param1 quoted2 "\'\':not_a_param2\'\'" \'\'\' foo from rdb$database', false);

returns

(
[19] => not_a_param1
)

It seems that getUnquotedStatementFragments() does not handle escaping by doubling single quotes correctly.






[DBAL-1204] Description of SQLParserUtils::getPlaceholderPositions() misleading Created: 24/Apr/15  Updated: 24/Apr/15

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

Type: Documentation Priority: Trivial
Reporter: Andreas Prucha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The description of this function is slightly misleading:

>> Returns an integer => integer pair (indexed from zero) for a positional statement and a string => int[] pair for a named statement. <<

This seems to be correct for positional parameters, but wrong for named parameters. According to the description i would expect the parameter names as keys and the positions as values, but the function returns an array with positions as key, and the parameter name of the position as value.






[DBAL-1203] [GH-839] Dbal 1200 Created: 22/Apr/15  Updated: 22/Apr/15

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 jbh-:

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

Message:

Add order by support in modify limit function for DB2. This takes care of DBAL-122(http://www.doctrine-project.org/jira/browse/DBAL-1200).

The current tests pass.






[DBAL-1202] JoinTable causes table already exists exception to be flung Created: 22/Apr/15  Updated: 22/Apr/15

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

Type: Bug Priority: Major
Reporter: Iain Cambridge Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   
/**
     * @var Collection
     * @ORM\ManyToMany(targetEntity="Foodpanda\Bundle\Core\CmsBundle\Entity\Tag", inversedBy="cmsPages")
     * @JoinTable(name="CmsCmsTags")
    */

The @JoinTable causes the exception to be flung when running schema create



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

Can't reproduce: please design a test case around the failure.

Comment by Iain Cambridge [ 22/Apr/15 ]

Can what you did to try and reproduce?

Comment by Iain Cambridge [ 22/Apr/15 ]

Also how are you guys even testing this? I can't see, therefore can't write a breaking test.

Comment by Marco Pivetta [ 22/Apr/15 ]

Iain Cambridge I created a test like following:

<?php

namespace Doctrine\Tests\ORM\Functional\Ticket;

/**
 * @group DDC-1452
 */
class DDC1452Test extends \Doctrine\Tests\OrmFunctionalTestCase
{
    protected function setUp()
    {
        parent::setUp();

        try {
            $this->_schemaTool->dropSchema(array(
                $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
                $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
            ));
        } catch (\Exception $e) {
            // ignored
        }
    }

    public function testIssue()
    {
        $this->_schemaTool->createSchema(array(
            $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
            $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
        ));
    }
}

/** @Entity */
class DDC9999EntityA
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;

    /**
     * @ORM\ManyToMany(targetEntity=DDC9999EntityB::class)
     * @JoinTable(name="CmsCmsTags")
     */
    private $b;
}

/** @Entity */
class DDC9999EntityB
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;
}
Comment by Iain Cambridge [ 22/Apr/15 ]

Thanks, so the test has to be in the ORM package?

Comment by Marco Pivetta [ 22/Apr/15 ]

Iain Cambridge yes, since it seems to be a mapping issue - see https://github.com/doctrine/doctrine2/tree/v2.5.0/tests/Doctrine/Tests/ORM/Functional/Ticket

Comment by Iain Cambridge [ 22/Apr/15 ]

This below fails for me.

<?php

namespace Doctrine\Tests\ORM\Functional\Ticket;

/**
 * @group DBAL-1202
 */
class DBAL1202Test extends \Doctrine\Tests\OrmFunctionalTestCase
{
    protected function setUp()
    {
        parent::setUp();

        try {
            $this->_schemaTool->dropSchema(array(
                $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
                $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
                $this->_em->getClassMetadata(DDC9999EntityC::CLASSNAME),
            ));
        } catch (\Exception $e) {
            // ignored
        }
    }

    public function testIssue()
    {
      var_dump($this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME));
        $this->_schemaTool->createSchema(array(
            $this->_em->getClassMetadata(DDC9999EntityA::CLASSNAME),
            $this->_em->getClassMetadata(DDC9999EntityB::CLASSNAME),
            $this->_em->getClassMetadata(DDC9999EntityC::CLASSNAME),
        ));
    }
}

/** @Entity */
class DDC9999EntityA
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;

    /**

     * @ManyToMany(targetEntity=DDC9999EntityC::class)
     * @JoinTable(name="CmsCmsTags")
     */
    private $b;
}

/**
 * @Entity
 * @Table(
 *      name="CmsCmstags",
 * )
 */
class DDC9999EntityB
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;

}

/**
  * @Entity
  * @Table(
  *      name="Cmstags",
  * )
  */
class DDC9999EntityC
{
    const CLASSNAME = __CLASS__;

    /** @Id @Column(type="integer") @GeneratedValue */
    private $id;
}

Comment by Marco Pivetta [ 22/Apr/15 ]

Seems an obvious failure to me - two declarations for the same table. What's the bug?

Comment by Iain Cambridge [ 22/Apr/15 ]

One entity uses cmscmstags and another cmstags. (Don't ask me why, just started)

Comment by Marco Pivetta [ 22/Apr/15 ]

Iain Cambridge I see that DDC9999EntityB has @Table(name="CmsCmstags"), and there is also a @JoinTable(name="CmsCmsTags")

Comment by Iain Cambridge [ 22/Apr/15 ]

I thought @table defines the table name for an entity. With @jointable defines the table to be used for a join. Are you saying they both define tables?

Comment by Marco Pivetta [ 22/Apr/15 ]

Yes, both cause a new table to be created on the DB.

Comment by Iain Cambridge [ 22/Apr/15 ]

I figured they would caused tables to be created but I wouldn't expect defining a join to cause an exception of defining a table twice. Especially since it seems quite possible and logical to use @JoinTable more than once?

Another quite possible and logical example would be one big entity and then only wanting a subset of that data for a join so use a smaller entity to hold that data.

Not saying the use case provided is exactly sane, however I would expect it to work.





[DBAL-1201] [GH-838] DBAL-95 Firebird Driver, Platform and Schema Manager Created: 22/Apr/15  Updated: 22/Apr/15

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 ancpru:

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

Message:

Hi,

I've implemented the driver for Firebird. It's currently tested with FB 2.5.

The driver uses the ibase-api. Originally I also had a PDO-based implementation. Despite it worked quite well in a real world application, it terribly failed in the Doctrine test suite because of strange transaction behaviour of the Firebird-PDO, thus I finally removed it.

The name of the driver is ibase_firebird, the platform name is firebird.

Because of the common ancestor Firebird an Interbase, it should be possible to use the implementation for Interbase, too. But this is not done nore tested, yet.

Andreas






[DBAL-1200] DB2 Platform doModifyLimitQuery ORDER BY Created: 21/Apr/15  Updated: 21/Apr/15

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

Type: Bug Priority: Minor
Reporter: Mark Gullings Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

IBM i v7r1



 Description   

Implement TODO note in doModifyLimitQuery

DB2Platform.php
    protected function doModifyLimitQuery($query, $limit, $offset = null)
    {
        if ($limit === null && $offset === null) {
            return $query;
        }
        $limit = (int) $limit;
        $offset = (int) (($offset)?:0);
        // Todo OVER() needs ORDER BY data!
        $sql = 'SELECT db22.* FROM (SELECT ROW_NUMBER() OVER() AS DC_ROWNUM, db21.* '.
               'FROM (' . $query . ') db21) db22 WHERE db22.DC_ROWNUM BETWEEN ' . ($offset+1) .' AND ' . ($offset+$limit);
        return $sql;
    }


 Comments   
Comment by Mark Gullings [ 21/Apr/15 ]

solution is in testing locally





[DBAL-1199] [GH-837] Revert the addition of the wrong bin script Created: 15/Apr/15  Updated: 15/Apr/15

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 stof:

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

Message:

The bin/doctrine-dbal.php file is not an executable file. Adding them as a bin in composer.json means that any composer install will trigger changes in the source when using symlinks because of the chmod. This makes things a pain when installing from source.
Thus, there is no valid reason to add it. It is absolutely not necessary when using a composer install. The issue requesting it previously is actually an issue in Laravel which replaces the proxy file/symlink generated by Composer with a copy of the original file, which of course cannot work because of paths used in require. But copying a second file does not help for that (unless in very specific cases). It only moves the issue until the next require call.



 Comments   
Comment by Doctrine Bot [ 15/Apr/15 ]

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





[DBAL-1198] [GH-836] Merge pull request #2 from doctrine/master Created: 10/Apr/15  Updated: 13/Apr/15  Resolved: 13/Apr/15

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 ancpru:

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

Message:

upd



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

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





[DBAL-1197] [GH-835] backport bugfix to avoid fatal error in array_merge during generating the table creation SQL Created: 10/Apr/15  Updated: 10/Apr/15

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 dbu:

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

Message:

2.5 includes this fix in 1c9fe8df . this pull request is just to backport the bugfix without further changes.

i verified on https://github.com/jackalope/jackalope-doctrine-dbal/pull/258 that this change indeed fixes the issue - but i don't know how to write a test for this.






[DBAL-1196] [GH-834] Update Connection.php Created: 09/Apr/15  Updated: 16/Apr/15  Resolved: 09/Apr/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Bill Schaller
Resolution: Fixed Votes: 0
Labels: connection, docblock, documentation, event


 Description   

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

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

Message:

These events don't exist.



 Comments   
Comment by Doctrine Bot [ 09/Apr/15 ]

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

Comment by Doctrine Bot [ 09/Apr/15 ]

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





[DBAL-1195] [GH-833] [DX] Added bool and int types Created: 09/Apr/15  Updated: 10/Apr/15  Resolved: 10/Apr/15

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: Steve Müller
Resolution: Invalid Votes: 0
Labels: bool, int, types


 Description   

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

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

Message:

Lately we have done similar thing for MongoDB ODM in https://github.com/doctrine/mongodb-odm/pull/1073 so I thought it will add value to DBAL as well. I've also changed ``integer`` and ``boolean`` to ``bool`` and ``int`` when used in PHP context. If this will be merged I can submit a PR to ORM docs as well



 Comments   
Comment by Doctrine Bot [ 09/Apr/15 ]

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





[DBAL-1194] [GH-832] Fix test failures on windows due to differing newlines Created: 08/Apr/15  Updated: 15/Apr/15  Resolved: 15/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ci, newlines, tests, testsuite, windows


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

Some tests were failing on windows due to differing newlines.

The tests which were failing used inline newlines in the comparison string, which evaluate to \r\n on Windows and \n on *nix.

The tests have been changed to use explicit newlines "\n".

Failure messages:
```
E:\wwwroot\dbal>vendor\bin\phpunit -c nodb.xml --filter "(testGetPlaceholderPositions|testDriverExceptionIsWrapped)" tests\Doctrine\Tests\DBAL
PHPUnit 4.0.20 by Sebastian Bergmann.

Configuration read from E:\wwwroot\dbal\nodb.xml

FFFFF.....................F............

Time: 2.8 seconds, Memory: 33.25Mb

There were 6 failures:

1) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #0 ('exec')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

2) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #1 ('query')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

3) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #2 ('executeQuery')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

4) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #3 ('executeUpdate')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

5) Doctrine\Tests\DBAL\ConnectionTest::testDriverExceptionIsWrapped with data set #4 ('prepare')
Failed asserting that exception message 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA": syntax error' contains 'An exception occurred while executing 'MUUHAAAAHAAAA':

SQLSTATE[HY000]: General error: 1 near "MUUHAAAAHAAAA"'.

6) Doctrine\Tests\DBAL\SQLParserUtilsTest::testGetPlaceholderPositions with data set #21 ('SELECT * FROM foo WHERE bar = \'it\\\'s a trap? \\\\\' OR bar = ?
AND baz = "\\"quote
" me on it? \\\\" OR baz = ?', true, array(58, 104))
Failed asserting that two arrays are equal.
— Expected
+++ Actual
@@ @@
Array (
0 => 58

  • 1 => 104
    + 1 => 105
    )

E:\wwwroot\dbal\tests\Doctrine\Tests\DBAL\SQLParserUtilsTest.php:71

FAILURES!
Tests: 39, Assertions: 44, Failures: 6.
```



 Comments   
Comment by Doctrine Bot [ 15/Apr/15 ]

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





[DBAL-1193] "requiresSQLCommentHint" is ignored by migration if the SQL type does not change Created: 08/Apr/15  Updated: 08/Apr/15

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

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


 Description   

I have found a previous issue, http://www.doctrine-project.org/jira/browse/DBAL-1085 which tells about the need to override "requiresSQLCommentHint" if the custom type uses an SQL type which is already known by Doctrine.

See also:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L327-L340

The bug: After I learned this and added the required TRUE return value, the migration (generated by "diff") won't contain the comment.

After adding the comment manually, everything works as expected.






[DBAL-1192] [GH-831] allow hhvm/mysqli failure so poor travis can feel better Created: 05/Apr/15  Updated: 05/Apr/15  Resolved: 05/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: allow-failures, ci, hhvm, mysqli, travis


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:



 Comments   
Comment by Doctrine Bot [ 05/Apr/15 ]

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

Comment by Doctrine Bot [ 05/Apr/15 ]

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





[DBAL-1191] [GH-830] Readme: nicer badges; cleanup, 2.3- dropped Created: 03/Apr/15  Updated: 07/Apr/15  Resolved: 07/Apr/15

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

Type: Documentation Priority: Minor
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 TomasVotruba:

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

Message:

Ref https://github.com/doctrine/doctrine2/pull/1362

Is there any reason why coverage is not in here? Would be much more useful than dependency badge.



 Comments   
Comment by Doctrine Bot [ 03/Apr/15 ]

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

Comment by Doctrine Bot [ 03/Apr/15 ]

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

Comment by Doctrine Bot [ 03/Apr/15 ]

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

Comment by Doctrine Bot [ 07/Apr/15 ]

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





[DBAL-1190] [GH-829] Pgsql connection test with charset parameter Created: 02/Apr/15  Updated: 02/Apr/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

This PR adds 2 tests for connecting to pgsql via PDOPgSql, while using a charset parameter.

Related to #828, #823






[DBAL-1189] [GH-828] rehashed charset implementation to support old versions of postgresql Created: 02/Apr/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.5, 2.5.1
Fix Version/s: 2.6, 2.5.2
Security Level: All

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Bill Schaller
Resolution: Fixed Votes: 0
Labels: charset, client_encoding, connection, driver, dsn, pdo_pgsql, pgbouncer, pgsql, postgresql, set-names


 Description   

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

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

Message:

My previous client_encoding fix turned out not to work on older postgres versions – BUT, the options param isn't supported by pgbouncer at all. SO, because there isn't consistent behavior with setting the character set via DSN - this change utilizes `SET NAMES`. I used SET NAMES since that is SQL standard and supported by PG.

I confirmed `SET NAMES` is supported all the way back to the older doc PG has, 7.1: http://www.postgresql.org/docs/7.1/static/multibyte.html



 Comments   
Comment by Doctrine Bot [ 02/Apr/15 ]

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





[DBAL-1188] Oracle Platform: List table columns are returned in the wrong order Created: 01/Apr/15  Updated: 01/Apr/15

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

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


 Description   

The function:

Doctrine\DBAL\Platforms\OraclePlatform::getListTableColumnsSQL

returns the columns sorted by name. This causes a problem in my application. Other platforms sort them on position. So when I build a model for a HTML table (placing datatype formatters for each column) the order of formatters gets messed up.

The equivalent method in other platforms like MySQL or PostgreSQL all make sure the order is preserved (the same as in the database).

To fix I changed

...ORDER BY c.column_name

to

...ORDER BY c.column_id





[DBAL-1187] [GH-827] Fix DISTINCT queries with limit and no order on SQL Server 2012 Created: 31/Mar/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: limit, mssql, offset, query, select-distinct, sql-server, sql-server-2012, sqlsrv


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

On SQLServer2012Platform, doModifyLimitQuery adds a do-nothing ORDER BY clause, because this is required in order to use OFFSET...FETCH NEXT N ROWS ONLY.

DISTINCT queries run via the paginator without an ORDER BY clause on SQL Server 2012 were failing with this error:

```
ORDER BY items must appear in the select list if SELECT DISTINCT is specified.
```

This PR fixes the error by adding 0 to the select list and changing the generated ORDER BY clause to read ORDER BY 1.

So a query that would have been generated as:
```sql
SELECT DISTINCT id_0
FROM (
SELECT p0_.id AS id_0
,p0_.preference_code AS preference_code_1
,p0_.id_zone AS id_zone_2
FROM preference p0_
WHERE (p0_.id_zone IN (2))
) dctrn_result
ORDER BY (SELECT 0)
OFFSET 0 ROWS FETCH NEXT 30 ROWS ONLY
```

Will now be generated as:
```sql
SELECT DISTINCT 0, id_0
FROM (
SELECT p0_.id AS id_0
,p0_.preference_code AS preference_code_1
,p0_.id_zone AS id_zone_2
FROM preference p0_
WHERE (p0_.id_zone IN (2))
) dctrn_result
ORDER BY 1
OFFSET 0 ROWS FETCH NEXT 30 ROWS ONLY
```



 Comments   
Comment by Doctrine Bot [ 08/Apr/15 ]

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





[DBAL-1186] [GH-826] fix incorrect ordering of columns in clustered indexes on sql server Created: 31/Mar/15  Updated: 16/Apr/15  Resolved: 16/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: clustered, columns, index, mssql, order, sqlserver, sqlsrv


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

When schema information is fetched from SQL server, the getListTableIndexesSQL was fetching index columns ordered by sys.index_columns.index_column_id. This was incorrect, because that column is simply a unique id for the column within the index. The column ordering information is actually in the key_ordinal column.

This PR changes SQLServerPlatform to generate a resultset ordered by key_ordinal instead of index_column_id.

This was causing schema diffs on tables with composite primary keys to try to drop and re-create the indexes every time the diff is run.

So this solves index churn in schema diffs on SQL server.



 Comments   
Comment by Doctrine Bot [ 15/Apr/15 ]

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





[DBAL-1185] [GH-825] Add postgresql 9.4 for travis builds Created: 30/Mar/15  Updated: 02/Apr/15  Resolved: 02/Apr/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ci, pgsql, postgresql, testing, travis


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:



 Comments   
Comment by Doctrine Bot [ 02/Apr/15 ]

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





[DBAL-1184] [GH-824] Added Postgres 9.4 platform (DBAL-1143) Created: 29/Mar/15  Updated: 29/Mar/15

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 mbeccati:

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

Message:

Features and changes:

  • jsonb can be used with: options= {"jsonb"=true}
  • OVER is no longer reserved
  • LATERAL is now reserved





[DBAL-1183] [GH-823] fix client_encoding setting to support pgbouncer Created: 27/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: charset, client_encoding, pgbouncer, pgsql, postgresql

Issue Links:
Reference
relates to DBAL-567 PDOPgSql should respect connection ch... Resolved

 Description   

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

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

Message:

The current release doesn't allow connecting to pgbcouner when specifying the charset due to the lack of support for the 'options' parameter. The fix is to use the client_encoding option directly instead of passing it through the options parameter.

This exact same bug was fixed in node.js's PG driver the exact same way.

https://github.com/brianc/node-postgres/pull/356

I've confirmed this fix works with pgbouncer.



 Comments   
Comment by Doctrine Bot [ 27/Mar/15 ]

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





[DBAL-1182] No schema difference detected when changing length of a text field Created: 26/Mar/15  Updated: 26/Mar/15

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

Type: Bug Priority: Major
Reporter: Evan Sheffield Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, schema-tool
Environment:

Database: MySQL 5.6



 Description   

I have a text field with a length specified that causes it to be chosen as TINYTEXT in MySQL.

/**  
 * @ORM\Column(name="message", type="text", length=255,  nullable=true)
 */
protected $message;

When I remove the length field from the annotation, I would expect the field to then be interpreted as LONGTEXT as specified in the documentation. However, when I run orm:schematool:update, it says that there is nothing to update.






[DBAL-1181] [GH-822] Fix for bad profiling data, showing an indefinitely long query Created: 26/Mar/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 1
Labels: logging, profiling


 Description   

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

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

Message:

This fix solves a problem where a failed transaction generates inaccurate profiling data.

In Symfony's "Timeline" profiler view, the bug makes it appear as if Symfony is taking a lot of time to process something, up until the very end of the request.



 Comments   
Comment by Doctrine Bot [ 08/Apr/15 ]

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





[DBAL-1180] [GH-821] Added method for switching support for foreign keys for SQLite Created: 25/Mar/15  Updated: 25/Mar/15

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 hason:

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

Message:






[DBAL-1179] [GH-820] SchemaManager quoting fixes Created: 19/Mar/15  Updated: 19/Mar/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

The SchemaManager, when used with SQL Server, fails to quote incoming table names and column names that should be quoted. That means that when a table that exists in the database called 'quote-address' needs to be dropped, the drop table statement will fail because the identifer is not marked as quoted when the schema diff is created.

This patch adds a method isValidIdentifier to the AbstractPlatform API - the purpose of this is to check if an identifier is valid to be used in SQL on the platform.

This is used by a new protected method in AbstractSchemaManager, quoteIncomingIdentifier. This method checks if the passed string literal is a valid identifier using isValidIdentifier. If the identifier is not valid, it quotes it for the platform and returns it. If it is valid, or is already quoted, it returns the identifier unchanged.






[DBAL-1178] Mapping import errors on SQL Server 2000 Created: 19/Mar/15  Updated: 23/Mar/15

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

Type: Bug Priority: Critical
Reporter: Ciro Vargas Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mapping, sqlserver
Environment:

Microsoft SQL Server 2000 - 8.00.2066 (Intel X86)
May 11 2012 18:41:14
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)


Attachments: PNG File System tables.png    

 Description   

The Doctrine documentation says:

SQLServerPlatform for version 2000 and above.

And the mapping query on the platform SQLServerPlatform.php is:

    public function getListTableColumnsSQL($table, $database = null)
    {
        return "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       " . $this->getTableWhereClause($table, 'scm.name', 'obj.name');
    }

But the system tables in the database is (attached)

There are several errors in queries using tables and fields that do not exist in SQL Server (in all map methods). So I can not map the entities



 Comments   
Comment by Marco Pivetta [ 19/Mar/15 ]

Ciro Vargas we don't support SQLServer 2000: the oldest version we support is SQLServer 2005 as per https://github.com/doctrine/dbal/blob/3b901cd314d1f79a54c93131d634aad507114b34/lib/Doctrine/DBAL/Platforms/SQLServer2005Platform.php

Comment by Benjamin Eberlei [ 19/Mar/15 ]

This doesnt end the world for you, you must extend from the SQL Server platform and change what you need.

Comment by Ciro Vargas [ 19/Mar/15 ]

Marco Pivetta http://doctrine-dbal.readthedocs.org/en/latest/reference/platforms.html in the docs says:

"SQLServerPlatform for version 2000 and above."

The right way is create mapping querys in the version platform and override on the upper, right? The doctrine team are updating the base platform

Comment by Ciro Vargas [ 19/Mar/15 ]

Benjamin Eberlei yes, i can do. Or mapping hardcoded

Comment by Ciro Vargas [ 19/Mar/15 ]

See on https://github.com/doctrine/dbal/blob/2a9e9943f33610bfde4637abeafe00edd201803c/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php

that's works no fine, but works

the right is update for each database version, no update only for the last.

Down versions of 2012 can be bugged too

Comment by Ciro Vargas [ 23/Mar/15 ]

Solved https://gist.github.com/cirovargas/e5c0bfbc404bb414bb2b





[DBAL-1177] Cannot drop index 'site': needed in a foreign key constraint. Doctrine drops index before create Created: 18/Mar/15  Updated: 18/Mar/15

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

Type: Bug Priority: Major
Reporter: seyfer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, migrations, schemadiff


 Description   

The problem is occurred when I generate migration for an entity on an existed database.
I'm add mapping from one table to table site. Generated migrations was like this

$this->addSql('ALTER TABLE request ADD CONSTRAINT FK_3B978F9F694309E4 FOREIGN KEY (site) REFERENCES sites (id)');
$this->addSql('DROP INDEX site ON request');
$this->addSql('CREATE INDEX IDX_3B978F9F694309E4 ON request (site)');

I'm already have index site on site column before generation migration, and migration tries, as you can see, first drop old index and than add new. But

[Doctrine\DBAL\Exception\DriverException]
An exception occurred while executing 'DROP INDEX site ON request':
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'site': needed in a foreign key constraint

[Doctrine\DBAL\Driver\PDOException]
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'site': needed in a foreign key constraint

If i change migration like that - all works.

$this->addSql('ALTER TABLE request ADD CONSTRAINT FK_3B978F9F694309E4 FOREIGN KEY (site) REFERENCES sites (id)');
$this->addSql('CREATE INDEX IDX_3B978F9F694309E4 ON request (site)');
$this->addSql('DROP INDEX site ON request');

I think migration should drop old or duplicate indexes AFTER adding new, not before.



 Comments   
Comment by mikeSimonson [ 18/Mar/15 ]

Wouldn't it make more sense not to touch the index at all ?

Comment by seyfer [ 18/Mar/15 ]

It generates automatically as is. I don't know why it tries add another index and drop mine. As I said - I add mapping on already existed table with index added by hand.
When I added a mapping - I need generate migration to sync my mapping and database. And it generates this migration.





[DBAL-1176] [GH-819] Added support for inline comments for SQLite Created: 18/Mar/15  Updated: 18/Mar/15

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 hason:

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

Message:






[DBAL-1175] [GH-818] Rebuild SQLServerPlatform::doModifyLimitQuery again to use a CTE Created: 17/Mar/15  Updated: 17/Mar/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

Also only uses 1 regex.

This method is vastly simpler and more reliable than the old method of parsing a whole lot of stuff.

A caveat: if a query is passed that contains a subquery with an ORDER BY clause, the inner ORDER BY clause will be dropped. SQL server doesn't support using ORDER BY inside subqueries. In the future I think we should consider throwing an exception when these are found.

For now, hold off on merging this. There is a PR open for the ORM Paginator that prevents it from sending queries with multiple ORDER BY clauses. The Paginator is the only place in the ORM where this occurs. Until that PR is merged, this one should probably stay open.

I'll be adding a set of functional tests for the Paginator later this week.






[DBAL-1174] [GH-817] Fixed a minor typo Created: 16/Mar/15  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: documentation, memory, sqlite, typo


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DBAL-1173] MySQL schema-tool:update fails if there are two tables with the same name (lower and uppercase) Created: 16/Mar/15  Updated: 16/Mar/15

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

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

ubuntu 14.04
php 5.5.12
mysql 5.6.19



 Description   

Hi,

when performing:
vendor/bin/doctrine orm:schema-tool:update --force --dump-sql

I get:

[RuntimeException]
Error Output:
[Doctrine\DBAL\Schema\SchemaException]
The table with name 'hospital.user_roles' already exists.

I have 2 tables with names USER_ROLES and user_roles in database, which are unrelated to the updated schema. They just exist in the db.

After deletion of one of them schema update works well.

Regards,
Andrzej






[DBAL-1172] [GH-816] Fix uses Statement::setFetchMode function in class Connection Created: 13/Mar/15  Updated: 15/Mar/15  Resolved: 15/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: fetch, fetch-mode, pdo


 Description   

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

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

Message:

I have a problem because interface function Connection::setFetchMode doesnt match PDOStatement::setFetchMode. Through Connection::setFetchMode I can send only first param to function PDOStatement::setFetchMode.
With this fix in Connection class, function Statement::setFetchMode used with call_user_func_array and this allow send more than one argument.
With this fix, I can use native PDO::FETCH_COLUMN like this:
$conn = $this->get('database_connection');
$conn->setFetchMode(\PDO::FETCH_COLUMN, 0);
$result = $conn->fetchAll("SELECT ..........");
and get full result array.
With function Connection::fetchColumn, I can take only the first row in result array.



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

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





[DBAL-1171] QueryBuilder - getForUpdateSQL Created: 13/Mar/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: QueryBuilder, lockhints


 Description   

It would be nice to be able to append FOR UPDATE in QueryBuilder.
Right now this is my workaround:

$qb = $connection->createQueryBuilder();
.......... qb stuffs .............
$stmt = $connection->executeQuery($qb->getSQL() . ' FOR UPDATE', $qb->getParameters());



 Comments   
Comment by Marco Pivetta [ 13/Mar/15 ]

This cannot be implemented, as FOR UPDATE is not cross-RDBMS compatible syntax.

Comment by Bojidar Hristov [ 13/Mar/15 ]

ORM supports it thru `$this->platform->getWriteLockSQL();`

Why DBAL not?

Comment by Marco Pivetta [ 13/Mar/15 ]

It's an implementation detail: each platform gets its own correct SQL generated. If you need platform-specific SQL, then don't use the query builder.





[DBAL-1170] self-referential column fails with sqlite and InheritanceType("JOINED") Created: 11/Mar/15  Updated: 11/Mar/15

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

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


 Description   

Per summary, if I have a base abstract class with a property referencing its own ID, and InheritanceType("JOINED"), the generated sqlite DDL will cause runtime constraint errors.

trimmed down example of what I'm doing, seeing

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="string")
 */
    
abstract class GraphElement  {
    /**
     * @Id 
     * @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     * @var int
     * */
    public $id;
            
    /**
     * @OneToOne(targetEntity="GraphElement")
     * @JoinColumn(name="owningProcessDefinition_id", referencedColumnName="id")
     * @var ProcessDefinition
     */
    protected $processDefinition = null;
......
}
/** @Entity **/
class ProcessDefinition extends GraphElement {}

Generates:
CREATE TABLE GraphElement (id INTEGER NOT NULL, name VARCHAR(255) NOT NULL, owningProcessDefinition_id INTEGER DEFAULT NULL, discr VARCHAR(255) NOT NULL, PRIMARY KEY(id), CONSTRAINT FK_4779DC6C1693DAAD FOREIGN KEY (owningProcessDefinition_id) REFERENCES GraphElement (id) NOT DEFERRABLE INITIALLY IMMEDIATE)

and then:

2015-03-11T15:46:15+00:00 [sql] "START TRANSACTION"
2015-03-11T15:46:15+00:00 [sql] INSERT INTO GraphElement (name, owningProcessDefinition_id, discr) VALUES (?, ?, ?)
2015-03-11T15:46:15+00:00 [sql] INSERT INTO ProcessDefinition (id, startState_id) VALUES (?, ?)
.....
2015-03-11T15:46:15+00:00 [sql] INSERT INTO GraphElement (name, owningProcessDefinition_id, discr) VALUES (?, ?, ?)
....
2015-03-11T15:46:15+00:00 [sql] UPDATE GraphElement SET owningProcessDefinition_id = ? WHERE id = ?
2015-03-11T15:46:15+00:00 [sql] "ROLLBACK"

will ultimately give:

Doctrine\DBAL\Exception\UniqueConstraintViolationException: An exception occurred while executing 'UPDATE GraphElement SET owningProcessDefinition_id = ? WHERE id = ?' with params [1, 1]:
SQLSTATE[23000]: Integrity constraint violation: 19 UNIQUE constraint failed: GraphElement.owningProcessDefinition_id' in /home/jwarnica/workspace/azBPM/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractSQLiteDriver.php:48

because of that "NOT DEFERRABLE INITIALLY IMMEDIATE"

Note: Everything just works with @InheritanceType("SINGLE_TABLE")

It does look like SqlitePlatform.php has the ability to not create this constraint, but I wasn't able to find any documentation on how (or if possible) to apply (loosen) FK constraints.

In any case, if SINGLE_TABLE just works, JOINED should trigger the right (no) constraints on self-referential OneToOne. Or at least have what one needs to do documented.






[DBAL-1169] [GH-815] Fix for inconsistent use of getSQLDeclaration Created: 11/Mar/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: case-sensitivity, type, typo


 Description   

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

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

Message:

I found an inconsistency in naming of the getSQLDeclaration method
I changed in 5 files `getSqlDeclaration` -> `getSQLDeclaration`



 Comments   
Comment by Doctrine Bot [ 13/Mar/15 ]

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

Comment by Doctrine Bot [ 13/Mar/15 ]

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





[DBAL-1168] Schema's getMigrateFromSql always adds CREATE SCHEMA Created: 11/Mar/15  Updated: 11/Mar/15

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

Type: Bug Priority: Major
Reporter: Varga Bence Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql, schematool
Environment:

Postgresql



 Description   

I originally posted this to Migrations; noticing that all the generated down() methods start with a "CREATE SCHEMA public" line.

Inspecting the return from Schema#getMigrateFromSql it indeed contains the create statement.






[DBAL-1167] [GH-814] allow serverVersion to be unspecified Created: 09/Mar/15  Updated: 09/Mar/15

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

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


 Description   

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

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

Message:

Hi,

this PR allows `serverVersion`to be nullable.

We use doctrine/dbal in Integration-Tests and to prevent the unit-tests from connecting to a database, we specify `serverVersion` with something made-up (like `5.6`).

However, i'm not comfortable set `serverVersion` to a made-up server-version to prevent connections from being made, when there even isn't a server to connect to. With this PR merged, we could specify `serverVersion` to be `null` instead of something like `5.6` and still prevent connections from being made. `null` is a valid return value for `getDatabasePlatformVersion()`.






[DBAL-1166] [GH-813] Treat SQLite Connection URLs Differently in DriverManager Created: 07/Mar/15  Updated: 07/Mar/15

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 chrisguitarguy:

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

Message:

In addition to setting `dbname`, which is ignored by the SQLite Driver, set the
`path` and `memory` params based on the database URL.

See DBAL-1164






[DBAL-1165] [GH-812] Treat SQLite Connection URLs Differently in DriverManager Created: 07/Mar/15  Updated: 07/Mar/15  Resolved: 07/Mar/15

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: drivermanager, sqlite


 Description   

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

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

Message:

In addition to setting `dbname`, which is ignored by the SQLite Driver, set the
`path` and `memory` params based on the database URL.

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

Not sure if this is a good solution, but it seemed more okay (less risky to BC) than changing the driver itself.



 Comments   
Comment by Doctrine Bot [ 07/Mar/15 ]

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





[DBAL-1164] Creating SQLite Connections via a URL Does Not Work Created: 07/Mar/15  Updated: 07/Mar/15

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

Type: Bug Priority: Minor
Reporter: Christopher Davis Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When creating a SQL light connection put the URL path into the `dbname` param. But the SQLite driver doesn't using the `dbname` param: it uses the `path` parameter.

So doing this:

$conn = DriverManager::getConnection([
'url' => 'sqlite:////some/path/here',
]);

Generates a PDO DSN like this: `sqlite:`. The path is completely ignored.

See the driver code here: https://github.com/doctrine/dbal/blob/6b6143ba16e5f17242835910173c033a8f73f845/lib/Doctrine/DBAL/Driver/PDOSqlite/Driver.php#L81-L88

`DriverManager` either needs some logic to use the path when it sees a sqlite URL or the Driver itself should use `dbname` (eg. check path, check dbname, check memory).



 Comments   
Comment by Christopher Davis [ 07/Mar/15 ]

Same is true for memory databases. `dbname` is set, but the driver never checks it.





[DBAL-1163] Pagination issue with order by statement Created: 05/Mar/15  Updated: 05/Mar/15

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

Type: Bug Priority: Major
Reporter: Vahe Shadunts Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator, postgresql
Environment:

linux, PostgreSQL



 Description   

For example I have 2 entities (family, person) with ManyToOne(familyId) association in Person entity, and OneToMany(mappedBy="familyId") in Family Entity (Full class definitions are in the end of description)

And this is my DQL part

$query = $em -> createQuery('
select e0, e1 from TestPagingBundle:Family e0 join e0.people e1
order by e1.firstName asc
');
$query -> setMaxResults(2);

This is working perfectly when the ordered firstNames are from different families.

But the paginator class generates 3 queries, 1st for fetching count, second for id's 3rd is a general query for data.

This is the 2nd Query:

SELECT DISTINCT id0, first_name3
FROM (
SELECT f0_.id AS id0, f0_.name AS name1, p1_.id AS id2, p1_.first_name AS first_name3, p1_.last_name AS last_name4
FROM family f0_
INNER JOIN person p1_ ON f0_.id = p1_.family_id
ORDER BY p1_.first_name ASC
)dctrn_result
ORDER BY first_name3 ASC
LIMIT 2

So in the select statement in this query there are distinctly selected 2 fields, id and first_name.

And if we'll have 2 people in one family which names are Aaron and Abraham, this query result will be

id | name
-------------------
1 | Aaron
1 | Abraham
-------------------

So we have fetched only one id from families instead of 2, which we wanted to select.

Then the where statement of 3rd query will be where id in ( ? ) with params [1,1], and we are getting 1 Family instead of 2.

----------------
class Family

{ /** * @var integer * * @ORM\Column(name="id", type="integer") * @ORM\Id * @ORM\GeneratedValue(strategy="IDENTITY") */ private $id; /** * @var string * * @ORM\Column(name="name", type="string", length=256, nullable=true) */ private $name; /** * @OneToMany(targetEntity="Person", mappedBy="familyId") **/ private $people; }

class Person

{ /** * @var integer * * @ORM\Column(name="id", type="integer") * @ORM\Id * @ORM\GeneratedValue(strategy="IDENTITY") */ private $id; /** * @ManyToOne(targetEntity="Family") * @JoinColumn(name="family_id", referencedColumnName="id") **/ private $familyId; /** * @var string * * @ORM\Column(name="first_name", type="string", length=256, nullable=false) */ private $firstName; /** * @var string * * @ORM\Column(name="last_name", type="string", length=256, nullable=true) */ private $lastName; }




[DBAL-1162] [GH-811] BlobType without fopen & allow_url_fopen Created: 05/Mar/15  Updated: 05/Mar/15

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 ahurt2000:

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

Message:

The allow_url_fopen parameter is disabled in many host providers by security. This commit introduces a small change to avoid the use of fopen function that this is affected by this parameter.






[DBAL-1161] [GH-810] Remove unneeded connect calls Created: 05/Mar/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: calls, connect, connection


 Description   

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

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

Message:

This PR removes a few unneeded calls to `Connection::connect()`



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

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





[DBAL-1160] Oracle - UuidGenerator bug Created: 04/Mar/15  Updated: 04/Mar/15

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

Type: Bug Priority: Major
Reporter: Loïc Lavoie Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

The current implementation of the generator strategy UUID for Oracle does not work with any of the version I have availalble (9-10-12)

When using it, the database raise an error the following error:

ORA-00923: FROM keyword not found where expected

The reason is that the statement return into the file DBAL\Plateform\OraclePlateform is missing the "FROM DUAL" (mandatory in oracle, you can't execute a query without a from).

Once this is fix, another error is raised:

ORA-01465: invalid hex number

The reason is that the getGuidExpression() return a binary result. Unfortunately, into the ORM part, it is not converted back in hex (using raw2hex).

My recommandation would be to simply return the following code in the OraclePlateform file:

    /**
     * {@inheritDoc}
     */
    public function getGuidExpression()
    {
        return 'RAWTOHEX(SYS_GUID()) FROM DUAL';
    }

This solution actually work on every plateform I've tested so far.






[DBAL-1159] [GH-809] travis: PHP 7.0 nightly added Created: 02/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: php-7.0


 Description   

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

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

Message:

Also fixed standard to 2 spaces, that's used above



 Comments   
Comment by Doctrine Bot [ 02/Mar/15 ]

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

Comment by Doctrine Bot [ 02/Mar/15 ]

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





[DBAL-1158] Using alias with order by and then applying a limit causes an SQL invalid column name error Created: 02/Mar/15  Updated: 02/Mar/15

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

Type: Bug Priority: Major
Reporter: Karl Dawson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, sqlsrv
Environment:

Windows Server 2012 with SQL Server 2012. Using PHP sqlsrv extension and SQL Native Client 11.



 Description   

I was originally having a problem where aliases were not working with order by/group by. I switched to 2.5.1 and this fixed the issue; however this led to another one. When applying a limit to a query using an alias in conjunction with order by, it generates the following error:

SQLSTATE [42S22, 207]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name 'sclr1'

See the following example:

$qb = $this->createQueryBuilder('u');

$select = array(
'u.title',
'SUM(u.seconds) AS total_seconds',
);

$qb->select($select)
->groupBy('u.title')
->orderBy('total_seconds', 'DESC')
->setMaxResults(5);

return $qb->getQuery()->getResult();

This will return the above error, but removing the setMaxResults(5) from the query will allow it to work.






[DBAL-1157] [GH-808] Compatibility layer for PHP installations without PDO support - ticket D... Created: 28/Feb/15  Updated: 28/Feb/15

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 AZielinski:

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

Message:

Even though DBAL currently offers non-PDO drivers, it depends on a number of PDO constants which renders it unusable if PHP was explicitly compiled without PDO. This PR is an attempt to shim PDO constants as stated in ticket DBAL-1156 (http://www.doctrine-project.org/jira/browse/DBAL-1156)



 Comments   
Comment by Doctrine Bot [ 28/Feb/15 ]

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





[DBAL-1156] Doctrine assumes that PDO is available Created: 23/Feb/15  Updated: 24/Feb/15

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

Type: Bug Priority: Major
Reporter: Adam Zielinski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: compatibility, dbal, mysqli, pdo


 Description   

`use PDO` and references to PDO class are seen in following files:
Connection.php
Statement.php
Cache/ArrayStatement.php
Cache/ResultCacheStatement.php
Driver/PDOConnection.php
Driver/Mysqli/MysqliStatement.php
Driver/OCI8/OCI8Statement.php
Driver/SQLSrv/SQLSrvStatement.php
Driver/Portability/Statement.php

It's all about using constants like PDO::FETCH_COLUMN. No actual methods are invoked, no objects are instantiated. This could be easily abstracted out to a class included in doctrine-dbal.

I stumbled upon this because I tried to use `mysqli` driver specifically because my installation of PHP is compiled with --disable-pdo.

As a quick & dirty workaround I included a file PDO.php with a shim, but it would be nice if Doctrine did not assume PDO is installed.

I am more than happy to prepare a pull request to fix it if you confirm this is something that needs attention.



 Comments   
Comment by Marco Pivetta [ 23/Feb/15 ]

Seems rather like a missing dependency in composer.json to me: we rely on PDO's APIs, and we're not really interested in polyfilling it when it's not available, as it's actually a lot of code to write for a little achievement :-\

Comment by Adam Zielinski [ 23/Feb/15 ]

Why provide non-PDO drivers then? In doctrine-dbal not a single method or object from PDO is used (aside of PDOConnection.php), it's all about accessing constants like PDO::PARAM_STR. This particular thing could be polyfilled very easily.

Comment by Marco Pivetta [ 23/Feb/15 ]

Those drivers work as long as PDO is also installed.

Comment by Adam Zielinski [ 23/Feb/15 ]

Sure they do, my point is that with minimal effort (that I offer to provide) those drivers could work without PDO as well. In fact that would make more sense - I can imagine that one of typical use cases for e.g. Mysqli driver is a situation where PDO cannot be used for some reason.

Correct me if I'm wrong, but I believe there is no real reason for doctrine-dbal to depend on PDO. Aside of accessing constants, PDO is only used by PDOConnection (which is only used by PDO-based drivers). PDO constants can be shimmed extremely easily.

Comment by Marco Pivetta [ 24/Feb/15 ]

Adam Zielinski if that's the minimal requirement, then a shim is fine





[DBAL-1155] [GH-807] Add support for named primary keys on SQL Server Created: 23/Feb/15  Updated: 23/Feb/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

This PR adds support for named primary keys on SQL Server, and fixes 2 SQL generation tests that should generate named primary keys to do so.






[DBAL-1154] [GH-806] Fix broken functional test for SQL server Created: 23/Feb/15  Updated: 26/Feb/15  Resolved: 26/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: phpunit, sql-server, sqlsrv, testing, tests


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

Fixes default constraints test for SQL server – table name was wrong.



 Comments   
Comment by Doctrine Bot [ 26/Feb/15 ]

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





[DBAL-1153] [GH-805] Allow symfony 3.0 components Created: 22/Feb/15  Updated: 22/Feb/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of nicolas-grekas:

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

Message:

Tests should tell if any deprecated interfaces of Symfony are used. If not, then the bundle is defacto compatible with 3.0






[DBAL-1152] [GH-804] bugfix(Jira1077): Correction for parenthesis misbehavior on querylimit for sqlserver Created: 21/Feb/15  Updated: 21/Feb/15

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 folcoerr:

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

Message:

bugfix(Jira1077): Correction for parenthesis misbehavior on querylimit for sqlserver

Correction added to production code
Test added for automated proof

Environment:
Windows 7/ Git Bash/ Sql Server
Test command line run : "./vendor/bin/phpunit -c ./sqlsrv.phpunit.xml --verbose ./tests/Doctrine/Tests/DBAL/Platforms/SQLServerPlatformTest.php"

Results:
![jira1077_dbalmaster_results](https://cloud.githubusercontent.com/assets/10148824/6312055/9d79743a-b96d-11e4-8842-5b9c649431a5.PNG)






[DBAL-1151] [GH-803] bugfix(Jira-1077): Correction for parenthesis misbehavior on querylimit for sql server Created: 21/Feb/15  Updated: 21/Feb/15

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 folcoerr:

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

Message:

bugfix(Jira-1077): Correction for parenthesis misbehavior on querylimit for sql server

Correction added to production code
Test added for automated proof

Environment:
Windows 7/ Git Bash/ Sql Server
Test command line run : "./vendor/bin/phpunit -c ./phpunit.xml --verbose ./tests/Doctrine/Tests/DBAL/platforms/SqlServerPlatformTest.php"

Results:
![jira1077_dbal24_results](https://cloud.githubusercontent.com/assets/10148824/6312030/298f9c02-b96d-11e4-80a6-d1f1e5fcc9ef.PNG)






[DBAL-1150] [GH-802] Fix issue where schema diffs on sql server try and fail to drop nonexistent indexes Created: 19/Feb/15  Updated: 19/Feb/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

When running a schema diff on SQL Server, the diff generated includes commands to drop indexes that don't exist. This doesn't fix that problem.

This patch works around the problem by changing sql generated like this:
```sql
IF EXISTS (SELECT * FROM sysobjects WHERE name = 'IDX_1234567890')
ALTER TABLE sometable DROP CONSTRAINT IDX_1234567890
ELSE
DROP INDEX IDX_1234567890 ON sometable
```

to this:

```sql
IF EXISTS (SELECT * FROM sysobjects WHERE name = 'IDX_1234567890')
ALTER TABLE sometable DROP CONSTRAINT IDX_1234567890
ELSE IF EXISTS (SELECT name FROM sysindexes WHERE name = 'IDX_1234567890')
DROP INDEX IDX_1234567890 ON sometable
```

Checking for the existence of the index to be dropped before trying to drop it.

The root of the problem, however, is that when the "from" schema is hydrated from schema-details via Table::__construct, a unique index is added for @JoinColumns that are flagged as unique. This also happens for joined table inheritance child tables.






[DBAL-1149] [GH-801] Add deprecated annotation to renameColumn method Created: 10/Feb/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: deprecated, rename-column, schema, table


 Description   

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

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

Message:

I added the deprecated annotation to warn a user that the method isn't working anymore. This will allow a dev to spot the deprecated method before he actually attempts to use it.

![screen shot 2015-02-10 at 09 55 50](https://cloud.githubusercontent.com/assets/594614/6124164/646f5f8e-b10b-11e4-9098-e1cb999d720d.png)

Should there be some comment added or perhaps a referring to the exception message?



 Comments   
Comment by Doctrine Bot [ 10/Feb/15 ]

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

Comment by Doctrine Bot [ 10/Feb/15 ]

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





[DBAL-1148] [GH-800] Add a Gitter chat badge to README.md Created: 09/Feb/15  Updated: 09/Feb/15  Resolved: 09/Feb/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of gitter-badger:

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

Message:

      1. doctrine/dbal now has a Chat Room on Gitter

@jwage has just created a chat room. You can visit it here: https://gitter.im/doctrine/dbal(https://gitter.im/doctrine/dbal?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&content=body_link).

This pull-request adds this badge to your README.md:

[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/doctrine/dbal?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=body_badge)

If my aim is a little off, please [let me know](https://github.com/gitterHQ/readme-badger/issues).

Happy chatting.

PS: [Click here](https://gitter.im/settings/badger/opt-out) if you would prefer not to receive automatic pull-requests from Gitter in future.



 Comments   
Comment by Doctrine Bot [ 09/Feb/15 ]

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

Comment by Doctrine Bot [ 09/Feb/15 ]

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





[DBAL-1147] [GH-799] Added option to set connect_timeout setting in PDOPgSql dsn Created: 09/Feb/15  Updated: 09/Feb/15  Resolved: 09/Feb/15

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

Type: Improvement 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 bashofmann:

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

Message:

See http://php.net/manual/en/function.pg-connect.php



 Comments   
Comment by Doctrine Bot [ 09/Feb/15 ]

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





[DBAL-1146] [GH-798] Add application_name to PostgreSQL driver Created: 04/Feb/15  Updated: 16/Mar/15

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 davividal:

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

Message:

PostgreSQL allows the user to set the application_name is connecting
to database. It is useful for monitoring purposes.
Currently one could just manually add 'application_name=foo' to DSN,
but having a parameter eases setting it using DoctrineBundle.



 Comments   
Comment by Davi Koscianski Vidal [ 16/Mar/15 ]

Hi, any thoughts on this?





[DBAL-1145] Add support for temporary tables Created: 01/Feb/15  Updated: 01/Feb/15

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

Type: New Feature Priority: Major
Reporter: Jeroen De Dauw Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Right now there is no real support for creating temporary tables. Having an interface that takes a Table and constructs temporary table creation sql from it would solve this.

Suggested by beberlei:

$table = new Table();
$table->addOption('temporary', true);
$platform->getCreateTableSQL( $table );






[DBAL-1144] [GH-797] unsigned boolean Created: 31/Jan/15  Updated: 06/Mar/15

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 liutec:

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

Message:



 Comments   
Comment by Doctrine Bot [ 06/Mar/15 ]

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





[DBAL-1143]  PostgreSQL PostgreSQL94 Created: 31/Jan/15  Updated: 31/Jan/15

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

Type: Task Priority: Minor
Reporter: Konstantin Nizhinskiy Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql


 Description   

Add new type jsonb
doc:
http://info.enterprisedb.com/rs/enterprisedb/images/EDB_White_Paper_Using_the_NoSQL_Features_in_Postgres.pdf






[DBAL-1142] [GH-796] Add tsvector type support in PostgreSQL Platform Created: 31/Jan/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: mapping, pgsql, postgresql, tsvector, type

Issue Links:
Duplicate
is duplicated by DBAL-1141 [GH-795] Add tsvector type support in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of believer-ufa:

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

Message:

This conversation continued in this request: https://github.com/doctrine/dbal/pull/795

I created test case and changed field type to "text". Test passes)



 Comments   
Comment by Doctrine Bot [ 01/Feb/15 ]

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

Comment by Doctrine Bot [ 10/Feb/15 ]

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

Comment by Doctrine Bot [ 10/Feb/15 ]

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





[DBAL-1141] [GH-795] Add tsvector type support in PostgreSQL Platform Created: 31/Jan/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

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: mapping, pgsql, postgresql, tsvector, type

Issue Links:
Duplicate
duplicates DBAL-1142 [GH-796] Add tsvector type support in... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of believer-ufa:

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

Message:

Just one simple string. Maybe add this to code?



 Comments   
Comment by Doctrine Bot [ 10/Feb/15 ]

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





[DBAL-1140] [GH-794] Update QueryBuilderTest.php Created: 30/Jan/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

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: Steve Müller
Resolution: Invalid Votes: 0
Labels: duplicate, query-builder, table-alias


 Description   

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

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

Message:

just testing if tests will fail



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

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





[DBAL-1139] [GH-793] fix SequenceName for Oracle Created: 30/Jan/15  Updated: 30/Jan/15

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 Gemorroj:

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

Message:

I want to use a new feature, specify the oracle IDENITY generator (http://www.doctrine-project.org/jira/browse/DDC-2875) . But after inserting a new row, doctrine causes the wrong sequence to find out the id of the inserted row. My problem is solved by adding processing the column name.






[DBAL-1138] [GH-792] getSQLForJoins - infinite recursion if join alias is not unique Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

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: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-1137 Infinite recursion on non-unique tabl... Resolved

 Description   

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

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

Message:

fix for exception message



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

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





[DBAL-1137] Infinite recursion on non-unique table/join alias in QueryBuilder Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

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

Type: Bug Priority: Major
Reporter: Steve Müller Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: alias, duplicate, infinite, non-unique, querybuilder, recursion

Issue Links:
Duplicate
is duplicated by DBAL-1138 [GH-792] getSQLForJoins - infinite re... Resolved
Reference
is referenced by DBAL-1136 [GH-791] Update QueryBuilderTest.php Resolved

 Description   

The QueryBuilder runs into an infinite recursion when using duplicate table aliases for table and/or join clauses:

$qb->select('a.id, b.id')
    ->from('table_a', 'a')
    ->join('a', 'table_b', 'b', 'a.fk_b = b.id')
    ->join('a', 'table_b', 'b', 'a.fk_b = b.id')
    ->join('b', 'table_a', 'a', 'a.fk_b = b.id');

Non-unique table aliases should be detected and an appropriate exception should be thrown instead.






[DBAL-1136] [GH-791] Update QueryBuilderTest.php Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

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: alias, duplicate, infinite, non-unique, querybuilder, recursion

Issue Links:
Reference
relates to DBAL-1137 Infinite recursion on non-unique tabl... Resolved

 Description   

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

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

Message:

test shows out of memory



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

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





[DBAL-1135] [GH-789] Fix when finding arrays of binary strings Created: 28/Jan/15  Updated: 29/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: array, binary, expansion, lob, parameter, sqlparserutils


 Description   

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

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

Message:

What the problem was
-------------------------
When using the ORM findBy() method to select data in a binary column (compared against an array of binary strings), I would get exceptions. Code example:

```php
/**

  • @param string[] $email_addresses Encrypted email addresses
  • @return \Project\Entity\EmailAddresses[]
    */
    public function retrieveEmailAddressEntities(array $email_addresses) { return $this->repository->findBy(['EmailAddress' => $email_addresses]); }

    ```

When I would only search for one binary string, however, everything would work correctly. I noticed I was getting a PHP Notice for array to string conversion in my error log:

```
PHP Notice: Array to string conversion in/var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php on line 91
```

In my MySQL table, the column is a varbinary(255) and the ORM entity was marked as type "binary".

How I fixed
--------------
I noticed that the `$type` in `SQLParserUtils::expandListParameters` was marking the type as 103. When this method was checking array types, it was not checking for binary strings. By simply adding the extra check for type 103 in this method, everything started working properly. Line comments below.

Extra
------
This worked to fix it for me and I haven't noticed any side effects of this, however I have not extensively tested all features. If there are any problems with this please let me know.

Specific file commit comments:
--------------------------------------
Connection.php

  • Added constant PARAM_LOB_ARRAY for binary

SQLParserUtils.php

  • Added check to see if the array type is binary
  • Changed the way that the foreach checked if the type was not equal to int, string, or binary





[DBAL-1134] [GH-788] Improved failure resilience for array type Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: array, array-type, exceptions, type, type-conversion, type-safety, validator


 Description   

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

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

Message:

The array type is the only one that throws an error if the value can't be decoded and that causes problems if the database column is empty or invalid. The patch adjusts the behavior to the rest of the implemented types.



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

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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





[DBAL-1133] [GH-787] Add left-over console file Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: binary, composer, console, tools


 Description   

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

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

Message:

`bin/doctrine-dbal` includes `bin/doctrine-dbal.php`, but the later is not symlinked to the `vendor/bin` directory of projects as it is not declared in composer.json. This PR declares the file as a vendor binary.



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

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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





[DBAL-1132] [GH-786] Fix removing autoincrement column from a primary key Created: 26/Jan/15  Updated: 10/Feb/15  Resolved: 10/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: alter-table, autoincrement, mysql, primary-key

Issue Links:
Reference
relates to DBAL-464 MySQL fails when try to drop a primar... Resolved

 Description   

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

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

Message:

https://github.com/doctrine/dbal/pull/430 is only a partial fix for DBAL-464. This adds treating autoincrement columns that get removed when altering a primary key.



 Comments   
Comment by Doctrine Bot [ 01/Feb/15 ]

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

Comment by Doctrine Bot [ 10/Feb/15 ]

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





[DBAL-1131] [GH-785] Handle default values for datetime/datetimetz columns in PostgreSQL Created: 25/Jan/15  Updated: 13/Mar/15

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

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


 Description   

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

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

Message:

(This was originally in #670 but am re-submitting due to a busted merge)

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

For example, the following statement:

`ALTER TABLE test_table ALTER test_column SET DEFAULT CURRENT_TIMESTAMP;`

Results in a column definition like:

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

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

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



 Comments   
Comment by Doctrine Bot [ 13/Mar/15 ]

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





[DBAL-1130] [GH-784] "Breaking" a test temporarily to show that it's not doing what is expect... Created: 23/Jan/15  Updated: 23/Jan/15

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 weaverryan:

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

Message:

Hi guys!

This is not meant to be merged, at least not yet. The test added in #691 is flawed. It's failing NOT because there is an exception when trying to use a closed connection (in fact, if the connection is closed, it simply re-opens), but instead, the exception is:

>
Access denied for user 'root'@'localhost' (using password: YES)

The tests should show this. The reason is that we're using connection parameters at the top of this class (https://github.com/doctrine/dbal/blob/master/tests/Doctrine/Tests/DBAL/ConnectionTest.php#L19) that, until now, were never used to actually connect to the database. But now, they are being used to connect to the database, but they're incorrect - they should be pulling from `TestUtil`.

So, this test needs to be fixed or removed.

Thanks!






[DBAL-1129] [GH-783] Fixes issue (DBAL-1057) use default platform when not connected Created: 23/Jan/15  Updated: 29/Jan/15

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 weaverryan:

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

Message:

Hi guys!

This is a fix for http://www.doctrine-project.org/jira/browse/DBAL-1057. It leaves the ability to set the platform and platform version from sha: 3176f51d1426022d305c6531a9b9bc93a868bddd, but does not try to connect if we're not already connected. This is consistent with the previous behavior (again see the linked sha) - before there was never a connection made to determine the platform.

The alternate solution is to connect, but surround this by a try-catch (`PDOException`, `DriverException`, `Exception`?) and return `null`. in case we have some situation where the database isn't created or the connection information is wrong.

I know this issue is causing a lot of problems around my world (I ran into myself yesterday), so thanks in advance for the attention.

Thanks!



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

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 29/Jan/15 ]

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





[DBAL-1128] [GH-782] Fix: SQLite offset with no limit support Created: 23/Jan/15  Updated: 24/Jan/15  Resolved: 24/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.5, 2.4.4, 2.5.1
Fix Version/s: 2.6, 2.4.5, 2.5.2
Security Level: All

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: limit, offset, paginator, select, sqlite, syntax


 Description   

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

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

Message:

Required for doctrine/doctrine2#1280

This just slipped through.

Should be merged into 2.4, 2.5 and 2.6



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

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DBAL-1127] [GH-781] Call detectDatabasePlatform only once Created: 22/Jan/15  Updated: 22/Jan/15

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 rosier:

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

Message:

Database platform detection is triggered twice if `Doctrine/DBAL/Connection::getDatabasePlatform()` is called before `Doctrine/DBAL/Connection::connect()`






[DBAL-1126] Amazon SimpleDB/DynamoDB Support Created: 21/Jan/15  Updated: 21/Jan/15

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

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


 Description   

Hello

Would you please to tell me if there is any plan to support ORM for Amazon SimpleDB/DynamoDB ? Thanks !



 Comments   
Comment by Marco Pivetta [ 21/Jan/15 ]

I don't see join support in AWS DynamoDB, therefore I don't see how support from our side can be provided





[DBAL-1125] [GH-780] Add autoload to composer.json Created: 20/Jan/15  Updated: 21/Jan/15  Resolved: 21/Jan/15

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

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


 Description   

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

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

Message:



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

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





[DBAL-1124] License notes whis porting of classes Created: 19/Jan/15  Updated: 20/Jan/15

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

Type: Task Priority: Minor
Reporter: Vladimir Khramov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I ported SQLParserUtils to zephir language for Phalcon 2 framework and used modified php tests for this class.

Phalcon licended by New BSD. Now I used default phalcon templates for files:
https://github.com/quantum13/cphalcon/blob/bind_array/phalcon/db/utils/sqlparser.zep
https://github.com/quantum13/cphalcon/blob/bind_array/tests/unit/Phalcon/Db/Utils/SQLParserTest.php

Please say, what I should to add to this files. Should I to add MIT license text to list of phalcon licenses?



 Comments   
Comment by Marco Pivetta [ 19/Jan/15 ]

The license clearly states:

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

You need to copy the LICENSE from https://github.com/doctrine/doctrine2/blob/2418f8f5e661c653e4b13cd433d569ece7318f62/LICENSE at least into the derived files, and keep a reference to the original author there.

Other than that, MIT, BSD-2-Clause and BSD-3-Clause are compatible.





[DBAL-1123] [GH-779] Initialize database schema only once per PHPUnit run Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: performance, phpunit, testsuite


 Description   

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

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

Message:

Currently the PHPUnit test suite recreates the database schema on each invocation of `TestUtil::getConnection()` which is highly inefficient and costly concerning performance, especially on platforms where schema recreation consumes a lot of time.
With this patch the database schema is initilaized once per PHPUnit run, increasing overall test suite runtime significantly.
For example using SQL Anywhere, database creation takes about 4-5 seconds which results in a complete test suite runtime of several minutes. With this patch the complete test suite runs in about 12-15 seconds *!*.



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

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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





[DBAL-1122] [GH-778] Cleanup PHPUnit test suite bootstrap Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: bootstrap, phpunit, testing


 Description   

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

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

Message:

Removes `require_once` statements leftovers in PHPUnit test classes in favour of properly bootstrapping via PHPUnit config files.



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

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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





[DBAL-1121] [GH-777] Make host and server connection parameters optional for sqlanywhere driver Created: 18/Jan/15  Updated: 18/Jan/15  Resolved: 18/Jan/15

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

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


 Description   

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

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

Message:

This patch makes it possible to connect to a SQL Anywhere database without having to specify `host` and/or `server` connection parameter.
The original assumption that the `server` parameter is necessary to connect to the database was wrong. It is only required if the host is running multiple named server instances and a specific instance should be connected to.
Also if the `host` parameter is not specified, it will default to `localhost` now.
The `LINKS` DSN parameter was replaced by the simpler and encouraged `HOST` parameter as the `LINKS` parameter is only required if you want to pass specific TCP/IP options.



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

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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





[DBAL-1120] [GH-776] Don't throw an exception during database platform guessing Created: 16/Jan/15  Updated: 19/Jan/15  Resolved: 19/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: connection, detection, platform


 Description   

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

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

Message:

Fallback to the "default" database platform if connecting to the database fails.

Fixes https://github.com/symfony/symfony-standard/issues/748



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

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





[DBAL-1119] [GH-775] fix diffColumn in text length is different Created: 16/Jan/15  Updated: 16/Jan/15  Resolved: 16/Jan/15

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 arima-ryunosuke:

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

Message:

Because mysql has multiple TEXT types.

```
$column1 = new Column('clobfield1', Type::getType('text'), array('Length' => 128));
$column2 = new Column('clobfield1', Type::getType('text'), array('Length' => 65536));

$platform = new MySqlPlatform();
var_dump($platform->getClobTypeDeclarationSQL($column1->toArray()));// this is "TINYTEXT"
var_dump($platform->getClobTypeDeclarationSQL($column2->toArray()));// this is "MEDIUMTEXT"

$c = new Comparator();
var_dump($c->diffColumn($column1, $column2));// this is empty!
```



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

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

Comment by Doctrine Bot [ 16/Jan/15 ]

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





[DBAL-1118] Schema does not create autoincrement keys for MySQL Created: 15/Jan/15  Updated: 16/Jan/15  Resolved: 16/Jan/15

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

Type: Bug Priority: Major
Reporter: Gabriel Birke Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

There seems to be no way to generate an autoincrementing primary key for MySQL with the the Schema class:

    $schema = new \Doctrine\DBAL\Schema\Schema;
    $table = $schema->createTable("foo");
    $table->addColumn('id', "integer", array("unsigned" => true);
    $table->setPrimaryKey(array("id"));
    $connectionParams = ["url" => "mysql://user:password@localhost/mydb"];
    $conn = \Doctrine\DBAL\DriverManager::getConnection($connectionParams, $config);
    $queries = $schema->toSql($conn->getSchemaManager()->getDatabasePlatform());
    foreach ($queries as $q) {
            echo "$q\n";
            $conn->exec($q);
     }

creates a table without autoincrementing keys. The SQL generated is as follows:

CREATE TABLE foo (id INT UNSIGNED NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

When I change the definition to

$table->addColumn('id', "integer", array("unsigned" => true, "autoincrement" => true));

instead, I get the following error:

SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key.

and the following SQL:

CREATE TABLE foo (id INT UNSIGNED AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

If there is a way to achieve this, please update the documentation.



 Comments   
Comment by Steve Müller [ 15/Jan/15 ]

This looks like a usage error. Can you please provide more information on how you create the table in the database? Those code snippets do show how you actually create the table in the database. Maybe also the executed SQL would help.

Comment by Gabriel Birke [ 15/Jan/15 ]

I've updated the code example. I can run the whole example locally and it generates a table "foo" with column "id" that is a primary key without autoincrement. Tried on two computers. Probably a usage error, but what am I missing?

Comment by Steve Müller [ 16/Jan/15 ]

Gabriel Birke thanks for the additional information. However we also need the exact SQL statements that are generated by $schema->toSql($conn->getSchemaManager()->getDatabasePlatform());
Thank you. Also are you using DBAL 2.5.1 (according to the ticket information)?

Comment by Steve Müller [ 16/Jan/15 ]

And please remember to gather the SQL when using autoincrement => true

Comment by Gabriel Birke [ 16/Jan/15 ]

Well, at least for my small test script it works now (it did not yesterday, but I don't know why).

Comment by Steve Müller [ 16/Jan/15 ]

Gabriel Birke both SQL statements are totally valid and expected to be generated this way. Also tried them out locally and they work perfectly. I guess it was a usage mistake somehow then. If it's working for you now I would like to close the issue

Comment by Steve Müller [ 16/Jan/15 ]

Ah you did already, thanks!





[DBAL-1117] id names not quoted on create in MySQL Created: 14/Jan/15  Updated: 14/Jan/15

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

Type: Bug Priority: Minor
Reporter: Anders Jenbo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 14.04, MySQL 5.5, MySQLi driver



 Description   

Having the following line in the xml configurations will cause creation to fail with a sql error because group is a key word.
<id name="group" association-key="true"/>






[DBAL-1116] [GH-774] Added SET and ENUM types for MySQL and fix issue with schema update tool Created: 14/Jan/15  Updated: 14/Jan/15  Resolved: 14/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: ddl, enum, mysql, set, type

Issue Links:
Dependency
is required for DBAL-4 missing column type "enum" Resolved
Reference
relates to DBAL-89 MySqlPlatform does not handle enum a... Resolved

 Description   

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

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

Message:

Set and Enum data types are one of the most popular. However, addition of these data types in the project creates a problem when updating of the database structure.



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

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

Comment by Doctrine Bot [ 14/Jan/15 ]

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

Comment by Marco Pivetta [ 14/Jan/15 ]

See http://stackoverflow.com/a/9057352/347063

ENUM and SET are non-portable types that will not be implemented by the DBAL due to the complexity behind their handling.





[DBAL-1115] [GH-773] Fix quoted identifiers for database creation SQL on SQL Anywhere Created: 13/Jan/15  Updated: 28/Jan/15  Resolved: 28/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: create-database, ddl, drop-database, identifier, quotation, sqlanywhere


 Description   

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

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

Message:

In SQL Anywhere the statements `CREATE DATABASE`, `DROP DATABASE`, `START DATABASE`, `STOP DATABASE` always take unquoted identifiers.
This PR ensures given identifiers are always passed unquoted to the generated SQL.
This issue was discovered by using DoctrineBundle's `database:create` and `database:drop` commands which always quote the database identifiers.

```bash
$ php app/console doctrine:database:create
Could not create database for connection named "symfony"
An exception occurred while executing 'START DATABASE '"symfony"' AUTOSTOP OFF':

SQLSTATE [00000] [-82] Angegebene Datenbank konnte nicht gestartet werden: Illegal character in database alias.
```



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

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DBAL-1114] Problem with drop database on PostgreSQL Created: 13/Jan/15  Updated: 13/Jan/15

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

Type: Task Priority: Minor
Reporter: Marcin Zawadzki Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-1093 [GH-757] Fix creating and dropping da... Resolved

 Description   

Hello,

After upgrading doctrine/dbal from version v2.4.3 to v2.4.4 I couldn't drop database by command line with zero open connections.

Example:

./app/console doctrine:database:drop --force
Could not drop database for connection named "test"
An exception occurred while executing 'DROP DATABASE "test"':

SQLSTATE[55006]: Object in use: 7 ERROR: cannot drop the currently open database

details:
• PostgreSQL 9.2.4
• PHP 5.5.10

Any suggestions or workarounds for this issue?

Thank you



 Comments   
Comment by Steve Müller [ 13/Jan/15 ]

Issue introduced in DBAL-1093, to be fixed in DoctrineBundle. PR provided: https://github.com/doctrine/DoctrineBundle/pull/368





[DBAL-1113] [GH-772] Problem with drop database on PostgreSQL Created: 13/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

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 Cinal:

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

Message:

Hello,

After upgrading doctrine/dbal from version v2.4.3 to v2.4.4 I couldn't drop database with zero open connections.

Example:

./app/console doctrine:database:drop --force
Could not drop database for connection named "test"
An exception occurred while executing 'DROP DATABASE "test"':

SQLSTATE[55006]: Object in use: 7 ERROR: cannot drop the currently open database

details:
��� PostgreSQL 9.2.4
��� PHP 5.5.10

Any suggestions or workarounds for this issue.

Thank you



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

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

Comment by Doctrine Bot [ 13/Jan/15 ]

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





[DBAL-1112] sqlite - Insert statement with keyword as column name raises sql-error Created: 12/Jan/15  Updated: 12/Jan/15  Resolved: 12/Jan/15

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

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


 Description   

We are using a sqlite db in our unit tests. During fixtures-load a error occurs:

[Doctrine\DBAL\Exception\SyntaxErrorException]
An exception occurred while executing 'INSERT INTO state (name, type, group) VALUES (?, ?, ?)':
SQLSTATE[HY000]: General error: 1 near "group": syntax error

We are using for all queries, in our symfony2 application, the doctrine-orm (v2.4.7). So this query is auto-generated.

The reason for this error is a wrong syntax of the insert statement:

INSERT INTO state (name, type, group) VALUES ('a_name', 'a_type', 'a_group');

The group column is a sqlite-keyword and must surround with " or '. A query like this

INSERT INTO state (name, type, 'group') VALUES ('a_name', 'a_type', 'a_group');

works fine.



 Comments   
Comment by Florian Semm [ 12/Jan/15 ]

I found the resolution in the documentation





[DBAL-1111] [GH-771] Fix unique index exception handling for an index on multiple columns in PHP 5.4 Created: 11/Jan/15  Updated: 11/Jan/15  Resolved: 11/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: exceptions, mysql, php-5.4, unique


 Description   

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

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

Message:

In SQLite under PHP 5.4, when I violate a unique index on multiple columns by creating a duplicate record, the PDO Exception thrown is "SQLSTATE[23000]: Integrity constraint violation: 19 columns X, Y are not unique". This PDO exception message is not parsed by the AbstractSQLiteDriver and converted to a UniqueConstraintViolationException as expected, and as happens in PHP 5.5, so only a generic DriverException is thrown, making error handling much harder.

This pull request adds "are not unique" as a string that is checked for in the exception handling code.



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

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

Comment by Doctrine Bot [ 11/Jan/15 ]

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





[DBAL-1110] [GH-770] Moved Doctrine\Tests namespace to composer autoload-dev. Created: 11/Jan/15  Updated: 11/Jan/15  Resolved: 11/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: autoloader, composer, phpunit, tests


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 11/Jan/15 ]

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





[DBAL-1109] unique-constraints names not quoted on create Created: 11/Jan/15  Updated: 12/Jan/15  Resolved: 12/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.4.3
Fix Version/s: 2.4.4, 2.6, 2.5.1
Security Level: All

Type: Bug Priority: Minor
Reporter: Anders Jenbo Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: create, index, quoted, table
Environment:

Ubuntu 14.04, MySQL 5.5, MySQLi driver

Actual version is 2.4.7 but it doesn’t appear on the list.



 Description   

Having the following line in the xml configurations will cause creation to fail with a sql error because unique is a key word.
<unique-constraint name="unique" columns="unique"/>

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 'un
ique (`unique`), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unic' at line 1






[DBAL-1108] [GH-769] Allow overriding implicit indexes Created: 08/Jan/15  Updated: 14/Jan/15  Resolved: 12/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: duplicate, explicit, fk, foreign-key, implicit, index, table

Issue Links:
Dependency
is required for DDC-2989 ORM should allow custom index names f... Resolved
Duplicate
is duplicated by DDC-3310 [GH-1138] Join column index names Resolved
Reference
relates to DBAL-1063 Exceptions from SchemaTool when runni... Resolved
relates to DBAL-1102 [GH-764] [DBAL-1063] Allow defining d... Resolved

 Description   

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

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

Message:

This is a follow-up patch for the change introduced in https://github.com/doctrine/dbal/pull/764.
It makes the `Table` class act more intelligent when it comes to preferring explicit over implicit indexes.
Currently it is necessary to construct a `Table` instance in a specific order to not have unnecessary duplicate indexes because of foreign keys. If you first add a foreign key and afterwards and explicit index that is fulfilling the implicit one, both indexes are stored. Instead it is more intelligent to replace the implicit by the explicit one if and only if the explicit one fulfills the implicit one.
This should also fix possible issues with how ORM's schema tool constructs a schema. See [here](https://travis-ci.org/doctrine/doctrine2/jobs/46321581#L307) where for a OneToOne relation on a primary key an additional regular index for the foreign key is created.



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

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

Comment by Doctrine Bot [ 09/Jan/15 ]

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





[DBAL-1107] Doctrine Migrations diff gets different table name for up and down Created: 06/Jan/15  Updated: 12/Jan/15

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

Type: Bug Priority: Minor
Reporter: Krzysztof Hasiński Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I've changed one field in my model from not null to default null, generated a migration using diff and got:

class Version20150105175136 extends AbstractMigration
{
    public function up(Schema $schema)
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('ALTER TABLE badge ALTER company_id DROP NOT NULL');
    }

    public function down(Schema $schema)
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != 'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

        $this->addSql('ALTER TABLE Badge ALTER company_id SET NOT NULL');
    }
}

Please note the name Badge and badge in up and down migrations. Is this a bug?

I've got response from Doctrine Migrations project:

"This should be reported in the issue tracker of the DBAL project, because the Migrations project is not responsible for computing the schema changes."

Link to this issue on github: https://github.com/doctrine/migrations/issues/197



 Comments   
Comment by Steve Müller [ 07/Jan/15 ]

Can you please provide the ORM mapping information before and after the migrations:diff command?
Did you maybe remove or add explicit quotes from/to your table name mapping? Really hard to evaluate without further information...

Comment by Krzysztof Hasiński [ 07/Jan/15 ]

Sure thing:

Entity (imports + header):

use Doctrine\ORM\Mapping as ORM;
use JsonSerializable;
use Iphp\FileStoreBundle\Mapping\Annotation as FileStore;
use Symfony\Component\Validator\Constraints as Assert;
/**
 * Badge
 * @FileStore\Uploadable
 * @ORM\Table()
 * @ORM\Entity
 */
class Badge implements JsonSerializable

Field before change:

    /**
     * @ORM\ManyToOne(targetEntity="Company")
     * @ORM\JoinColumn(nullable=false)
     */
    private $company;

Field after change:

    /**
     * @ORM\ManyToOne(targetEntity="Company")
     * @ORM\JoinColumn(nullable=true)
     */
    private $company;

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

How is your table named in the database? Is it "Badge" or "badge"? I assume that your table was created with the name "Badge" (with a capital letter). If this is the case, did you have your table name explicitly quoted in the mapping some time before like `Badge` or "Badge" (including backticks/quotes)?

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

Created using migrations:diff, relevant line (note the capital letter):

        $this->addSql("CREATE TABLE Badge (id INT NOT NULL, user_id INT DEFAULT NULL, team_id VARCHAR(63) NOT NULL, name VARCHAR(255) NOT NULL, image VARCHAR(512) NOT NULL, condition TEXT NOT NULL, PRIMARY KEY(id))");

In all subsequent migrations any ALTER TABLE (generated) is using this mixed case for up and down.

Status in db now (from psql):

khasinski=> \d badge
                          Table "public.badge"
   Column    |          Type           |            Modifiers            
-------------+-------------------------+---------------------------------
 id          | integer                 | not null
 user_id     | integer                 | 
 company_id  | character varying(63)   | not null
 name        | character varying(255)  | not null
 image       | text                    | not null
 condition   | text                    | 
 description | character varying(1024) | default NULL::character varying
Indexes:
    "badge_pkey" PRIMARY KEY, btree (id)
    "idx_3f316719296cd8ae" btree (company_id)
    "idx_3f316719a76ed395" btree (user_id)
Foreign-key constraints:
    "fk_3f316719296cd8ae" FOREIGN KEY (company_id) REFERENCES company(id)
    "fk_3f316719a76ed395" FOREIGN KEY (user_id) REFERENCES guser(id)
Referenced by:
    TABLE "userbadge" CONSTRAINT "fk_9a64d968f7a2c2fc" FOREIGN KEY (badge_id) REFERENCES badge(id)
Comment by Marco Pivetta [ 09/Jan/15 ]

Can you please tell us the exact versions (see composer.lock) of the DBAL, ORM and migrations installed?

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

Sure, always happy to help

DBAL:

            "name": "doctrine/dbal",
            "version": "v2.5.0",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/dbal.git",
                "reference": "71140662c0a954602e81271667b6e03d9f53ea34"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/dbal/zipball/71140662c0a954602e81271667b6e03d9f53ea34",
                "reference": "71140662c0a954602e81271667b6e03d9f53ea34",
                "shasum": ""
            },

ORM:

            "name": "doctrine/orm",
            "version": "v2.4.7",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/doctrine2.git",
                "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/doctrine2/zipball/2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
                "reference": "2bc4ff3cab2ae297bcd05f2e619d42e6a7ca9e68",
                "shasum": ""
            },

Migrations:

            "name": "doctrine/doctrine-migrations-bundle",
            "version": "dev-master",
            "target-dir": "Doctrine/Bundle/MigrationsBundle",
            "source": {
                "type": "git",
                "url": "https://github.com/doctrine/DoctrineMigrationsBundle.git",
                "reference": "81575a4316951125ce408c70f30547c77d98f78a"
            },
            "dist": {
                "type": "zip",
                "url": "https://api.github.com/repos/doctrine/DoctrineMigrationsBundle/zipball/81575a4316951125ce408c70f30547c77d98f78a",
                "reference": "81575a4316951125ce408c70f30547c77d98f78a",
                "shasum": ""
            },
Comment by Steve Müller [ 09/Jan/15 ]

I think I get the problem here. Btw do the migrations actually fail? IMO this is not really an "issue" as casing of identifiers is ignored by PostgreSQL unless you explicitly quote identifiers. So:

ALTER TABLE badge ALTER company_id DROP NOT NULL;
ALTER TABLE Badge ALTER company_id DROP NOT NULL;
ALTER TABLE BADGE ALTER company_id DROP NOT NULL;

all do the same thing because PostgreSQL internally lowercases identifiers if they are not quoted.
Please see: http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html#.VLAQal0z1C0

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

BTW if you find it annoying that migrations uses "Badge" instead of "badge" you'll just have to use another naming strategy.
See: http://doctrine-orm.readthedocs.org/en/latest/reference/namingstrategy.html

Comment by Krzysztof Hasiński [ 09/Jan/15 ]

I am well aware, that PostgreSQL use lowercase when it comes to table names without a quote, that's why I'm not considering a major bug, just some inconsistency, that I was curious about. It seems like up and down migrations should read the data from a single source of truth.

I might be mistaken, but it seems like migrations are important enough to care about this kind of minor details.

Comment by Steve Müller [ 12/Jan/15 ]

The DBAL schema manager that introspects your database does not know about your schema mappings you defned in ORM so it won't know that you created the table with an uppercase first letter. If you want consistency, please use another naming strategy in ORM or quote your table identifier explicitly in your mapping.
Doctrine will only quote reserved keyword identifiers and does not quote all identifiers automatically. There have been several discussions about this to why auto-quoting brings more problems than it solves.

Comment by Krzysztof Hasiński [ 12/Jan/15 ]

As I said - I am aware of that and it's probably ok

So my understanding is that it creates "up" migrations from ORM (which knows about the capital letter) and "down" using DBAL schema manager, is that correct?

Comment by Steve Müller [ 12/Jan/15 ]

I think you mean the other way around. See here: https://github.com/doctrine/migrations/blob/master/lib/Doctrine/DBAL/Migrations/Tools/Console/Command/DiffCommand.php#L101-L102
For "up" migrations the ORM schema mapping is compared against the database schema mapping (base). For "down" migrations it's the other way around.





[DBAL-1106] [GH-768] [DBAL-1106] Improve schema introspection performance on Oracle Created: 04/Jan/15  Updated: 04/Jan/15  Resolved: 04/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, introspection, oracle, performance, schema


 Description   

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

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

Message:

This PR improves the overall schema introspection performance on Oracle by optimizing some of the `getList*()` method SQL queries in the platform.
Unfortunately Oracle system views are rather slow, especially when joining tables. Using subqueries can improve the execution time a lot.

*Improved queries*

(the times have been measured using an exemplary query from the functional test suite)

`getListTableForeignKeysSQL()`: Down from `~2.33s` to `~0.68s` per query
`getListTableColumnsSQL()`: Down from `~0.49s` to `~0.14s` per query
`getListTableIndexesSQL()`: Down from `~0.5s` to `~0.25s` per query

Overall improvement of `OracleSchemaManagerTest` from `~100s` to `~37.5s`.

I was quite impressed by the performance improvements



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

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

Comment by Doctrine Bot [ 04/Jan/15 ]

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





[DBAL-1105] [GH-767] Removed drizzle support. Created: 04/Jan/15  Updated: 04/Jan/15

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 kimhemsoe:

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

Message:






[DBAL-1104] [GH-766] [DBAL-1104] Add support for object hydration in oci8 driver Created: 04/Jan/15  Updated: 04/Jan/15  Resolved: 04/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: driver, fetch, object, oci8, oracle


 Description   

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

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

Message:

Adds support for fetching data into `\stdClass` objects in `oci8` driver.



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

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

Comment by Doctrine Bot [ 04/Jan/15 ]

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





[DBAL-1103] [GH-765] Remove PHP 5.3 support Created: 03/Jan/15  Updated: 03/Jan/15

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 Ocramius:

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

Message:

Just a suggestion for master (2.6). We should move on.



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

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





[DBAL-1102] [GH-764] [DBAL-1063] Allow defining duplicate indexes on a table Created: 03/Jan/15  Updated: 08/Jan/15  Resolved: 03/Jan/15

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

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

Issue Links:
Reference
relates to DBAL-1063 Exceptions from SchemaTool when runni... Resolved
is referenced by DBAL-1108 [GH-769] Allow overriding implicit in... Resolved

 Description   

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

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

Message:

This PR removes silent dropping of "duplicate" indexes on a table if two indexes fulfill each other or one overrules the other.
This is necessary to make detection of renamed indexes work properly (introduced in 2.5). Currently there are situations where false positive index renamings are detected because of race conditions.

*Example*

An ORM entity contains an association which adds a foreign key constraint to the underlying table. Foreign key constraints always create implicit indexes on the particular columns.
The entity also contains a mapping for a custom named index fulfilling the foreign key column(s).
The ORM schema tool first adds the foreign key constraint to the table, implicitly creating an index. Afterwards it adds the custom named index which is dropped silently by the table instance because it is considered a "duplicate".
So the table instance created by the schema now contains the auto generated index but not the custom named one.
When using the schema tool to update the schema, the DBAL schema manager is utilized to create the "online" schema. The schema manager detects two indexes in the database, the auto generated one and the custom named one (manually created by the user).
When the schema manger creates the table instance it eventually adds the custom named index first which results in the auto generated index being dropped silently.
When comparing both "offline" and "online" schema, the comparator detects an index rename which actually is none.
This leads to failing `DROP INDEX` and `CREATE INDEX` SQL.

Besides this issue "duplicate" indexes are totally legit and DBAL should not decide whether or not to create an index. This should be user responsibility.

This implementation is much more transparent and less error prone and opens up more flexibility for the user to define indexes on tables.

/cc @flack @Ocramius @beberlei



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

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1101] [GH-763] Add date formatting and from/to unix timestamp conversion Created: 03/Jan/15  Updated: 05/Jan/15  Resolved: 05/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: conversion, date, format, sql, timestamp, unix


 Description   

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

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

Message:

I'm proposing to add date formatting as well as from/to unix timestamp conversion to DBAL. If this PR is going to find resonance I'd gladly add implementations for SQlite and MySQL.

Please let me know if this is something worth to pursue.



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

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





[DBAL-1100] [GH-762] PostgreSQL needs explicitly closed connection in functional test Created: 03/Jan/15  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: connection, postgresql, process-isolation, tests


 Description   

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

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

Message:

The test `Doctrine\Tests\DBAL\Functional\ConnectionTest::testConnectWithoutExplicitDatabaseName` prevents further tests in the suite from being run as the connection hangs around in PostgreSQL.

After this particular test, when the next `DROP DATABASE` is run, the log shows:

> 2015-01-03 00:21:28 PST ERROR: database "doctrine_tests" is being accessed by other users
> 2015-01-03 00:21:28 PST DETAIL: There is 1 other session using the database.
> 2015-01-03 00:21:28 PST STATEMENT: DROP DATABASE doctrine_tests

And the next functional test to be run produces something like:

> 1) Doctrine\Tests\DBAL\Functional\ConnectionTest::testPingDoesTriggersConnect
> Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'CREATE DATABASE doctrine_tests':
>
> SQLSTATE[42P04]: Duplicate database: 7 ERROR: database "doctrine_tests" already exists
>
> ...

This is with the following:

  • Debian Linux
  • PHP 5.5.9
  • PostgreSQL 9.3.5
  • PHPUnit 4.0.20
  • Process Isolation = off

Turning process isolation on does resolve the issue, but I assume that shouldn't be required. This doesn't seem to affect Travis.



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

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1099] Unittests for Drizzle Platform Created: 02/Jan/15  Updated: 07/Jan/15  Resolved: 07/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Claudio Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: Drizzle, dbal


 Description   

I've realized that the DrizzlePlatform has no unittests at the moment and it should get some. Usually unittests are a must have and every new code should get their tests. DrizzlePlatform is not a new contribution so I'm wodering why it lacks unittests.

What are the reasons that DrizzlePlatform has no unittests?



 Comments   
Comment by Marco Pivetta [ 02/Jan/15 ]

What are the reasons that DrizzlePlatform has no unittests?

It probably just got in when we weren't strict about tests (nor had CI integration yet)

Comment by Claudio [ 02/Jan/15 ]

Sounds to me like unittests are welcome.

Comment by Benjamin Eberlei [ 02/Jan/15 ]

We should rather be removing Drizzle support in an upcoming version (DBAL 2.6), as the database is not developed anymore.

Comment by Marco Pivetta [ 02/Jan/15 ]

Tests are always very welcome.

Comment by Claudio [ 02/Jan/15 ]

Benjamin Eberlei You're more into never touch DrizzlePlatform again? I didn't know that Drizzle isn't developed anymore and I'm not sure if anyone is even using Drizzle with Doctrine DBAL.

Comment by Claudio [ 07/Jan/15 ]

Since Benjamin Eberlei suggested to remove Drizzle and a PR already exists for that (DBAL-1105) (https://github.com/doctrine/dbal/pull/767), I close this issue.





[DBAL-1098] [GH-761] Fixed typo Created: 02/Jan/15  Updated: 02/Jan/15  Resolved: 02/Jan/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: typo


 Description   

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

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

Message:



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

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





[DBAL-1097] [GH-760] [DBAL-1097] Fix foreign key constraint referential action on Oracle Created: 31/Dec/14  Updated: 01/Jan/15  Resolved: 01/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: action, constraint, fk, foreignkey, noaction, ondelete, oracle, referential, restrict


 Description   

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

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

Message:

Oracle only supports `CASCADE` and `SET NULL` referential actions for foreign key constraints. It also supports `NO ACTION` but it cannot be declared with an explicit `ON DELETE NO ACTION` clause. The complete clause has to be omitted in order to make it work.
This PR fixes supported referential actions and omits the referential clause if either action `NO ACTION` or `RESTRICT` is set for the foreign key constraint to create.



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

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

Comment by Doctrine Bot [ 01/Jan/15 ]

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





[DBAL-1096] schema-tool:update does not understand columnDefinition correctly Created: 30/Dec/14  Updated: 08/Jan/15  Resolved: 31/Dec/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Morel Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-167 Schema comparator doesn't work proper... Open
Reference
relates to DDC-1657 The Doctrine cli tool does not handl... Resolved
relates to DDC-625 orm:schema-tool:update --dump-sql sho... Resolved

 Description   

This issue is similar to the old DDC-625 and to DDC-1657, but its scope is limited to columns declared with columnDefinition.

Take this entity:

class Faq
{
    /**
     * @ORM\Column(type="integer", columnDefinition="TINYINT(3) UNSIGNED NOT NULL")
     *
     * @var integer
     */
    private $position;
}

The command doctrine orm:schema-tool:update --dump-sql generates the following output:

ALTER TABLE Faq CHANGE position position TINYINT(3) UNSIGNED NOT NULL;

Even though the column is already declared this way. If I manually execute this query, and run the tool again, I get the same output.

I'm using Doctrine 2.4.7 with PHP 5.5.12 and MySQL 5.6.17.



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

The schema tool can't and won't handle diffs containing custom columnDefinition.

Comment by Benjamin Morel [ 31/Dec/14 ]

@ocramius Can you tell me why? Can't it at the very least compare them as strings, to avoid repeating endlessly the same queries?

Comment by Marco Pivetta [ 31/Dec/14 ]

That's exactly the problem: string comparison won't work in these cases, because of minor mismatches and because the column definition may include special markers, comments, definitions and so on in scrambled order.

This limitation is also documented in http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html#column

Handling it goes beyond the scope of the schema comparator, as the complexity to deal with it is not worth the effort.

Comment by Benjamin Morel [ 31/Dec/14 ]

While I fully understand these concerns, it's really disappointing to have to either stick to default, unoptimized data types such as INT when you only need a 8- or 16-bit integer, or to have to give up the command-line schema validation tool that will always go red.

The same issue applies when using custom data types such as Geometry or LocalDate, even when using supported SQL declarations.
This restricts a lot what you can do with the ORM while keeping the convenience of the schema tools!

I may have a few ideas to try out to make this work; if the core team is not 100% opposed to the concept, I could open a PR with a proof of concept at some point.

Comment by Marco Pivetta [ 31/Dec/14 ]

Fine tuning is the job of a DBA, not of the schema-tool. The schema-tool is by far a silver bullet.

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

Benjamin Morel if you find a way to make custom columnDefinitions comparable in a reasonable way, go ahead, make a contribution. It's not that we are totally against it, we just didn't find a good solution so far to make it work in a usable way. By the way, this is actually a DBAL issue, moving.

Comment by Christophe Coevoet [ 31/Dec/14 ]

Note that for custom data types, the SchemaTool supports comparing them if you use custom DBAL types to map them instead of using an existing type and adding a customDefinition property in it (the result might even be a better integration)

Comment by Benjamin Morel [ 31/Dec/14 ]

@Christophe Hmm I'm going to play a bit with this, but the LocalDate custom type I mentioned above, even though it uses $platform->getDateTypeDeclarationSQL(), is not properly handled by the SchemaTool either (it also endlessly suggests the same DDL)!

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

Benjamin Morel try making your custom type a commented type. This should make the schema manager be able to distinguish your custom type from the default DateType.
Override the method requiresSQLCommentHint() in your custom type class and let it return true.

Comment by Benjamin Morel [ 05/Jan/15 ]

Steve Müller It works indeed with requiresSQLCommentHint(), I didn't know about that, thank you.

As far as I can see, the commented types are not checked by the SchemaTool: if I manually change a commented column type in the database, schema-tool:update won't offer me to fix it.

Could we do the same thing for columns with a columnDefinition? i.e. comment them with DC2Type:integer or DC2Type:string or whatever the native type is, and have the SchemaTool skip them?

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

Benjamin Morel actually it is the DBAL schema manager that is extracting the custom type name from the column's comment and then mapping it accordingly.
For instance if your custom type is called "money" (which is based on the native "decimal" type for example), DBAL will add the string "(DC2Type:money)" to the column's comment on creation/update. On reverse engineering the column from the database the schema manager will first detect the column as "decimal" (native type), then check for the custom type string in the comment and convert it into the "money" type.
This should work out of the box but is processed by DBAL, not ORM's schema tool. The schema tool just utilizes DBAL's schema manager here.
Speaking of custom columnDefinition your idea sounds reasonable to me and I think to remember that something similar has been proposed in the past. However to make matching and extraction easier we should hash the columnDefinition string somehow.

Comment by Benjamin Morel [ 05/Jan/15 ]

Steve Müller Including a hash of the column definition in the DC2Type comment is a good idea, however it would only detect when you update the definition in the entity, not when you update the column type in the database manually.

I would be happy to work on this suggestion anyway, but I'm not sure where to start as I'm not comfortable with the internals of the schema manager.

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

Benjamin Morel of course we would have to make a compromise here. Comparing the column declaration SQL coming from the database with an arbitrary column declaration string from the mapping is not safe and also impossible considering that you usually use the columnDefinition to define vendor specific semantics for the column that DBAL does not/cannot support.
Implementing this feature would be similar to the commented type one.

Places to start:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L1085-L1112
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L129-L132 (needs to be adopted for all schema managers)
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L497-L525

Those should be the important parts to adopt. Feel free to provide a PR

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

Related: DBAL-167





[DBAL-1095] [GH-759] [DBAL-1095] Fix index introspection on SQL Anywhere Created: 28/Dec/14  Updated: 28/Dec/14  Resolved: 28/Dec/14

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

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


 Description   

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

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

Message:

SQL Anywhere creates indexes implicitly for foreign key constraints. Thoses should not be introspected by the schema manager to avoid unnecessary schema updates with ORM's schema tool. DBAL already creates indexes for foreign key constraints implicitly...



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

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

Comment by Doctrine Bot [ 28/Dec/14 ]

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





[DBAL-1094] [GH-758] Cleanup travis database creation Created: 26/Dec/14  Updated: 27/Dec/14  Resolved: 27/Dec/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: travis


 Description   

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

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

Message:

Remove database creation from Travis build script because it is actually done by DBAL test suite already. Moreover it avoids creating temp databases which are useless and not even used by PostgreSQL currently.



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

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

Comment by Doctrine Bot [ 27/Dec/14 ]

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





[DBAL-1093] [GH-757] Fix creating and dropping database on PostgreSQL Created: 26/Dec/14  Updated: 13/Jan/15  Resolved: 27/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: create, database, drop, pgsql, postgresql

Issue Links:
Reference
is referenced by DBAL-1114 Problem with drop database on PostgreSQL Open

 Description   

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

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

Message:

There is some useless code in the schema manager for PostgreSQL for creating and dropping a database. Moreover if either of those operations fails, the schema manager stays in an inconsistent state because the temporary connection that is set in the schema manager is not reverted back to the original connection.



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

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

Comment by Doctrine Bot [ 27/Dec/14 ]

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





[DBAL-1092] [GH-756] [DBAL-1062] Fix renaming indexes used by foreign key constraints Created: 24/Dec/14  Updated: 26/Dec/14  Resolved: 26/Dec/14

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

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

Issue Links:
Reference
relates to DBAL-1062 upgrade from v2.4.3 to v2.5.0 is forc... Resolved

 Description   

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

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

Message:

Platforms that do not support a SQL syntax for natively renaming indexes need to drop and recreate indexes to perform a rename.
Platforms like MySQL < 5.7 deny dropping indexes used by foreign key constraints. In this case foreign key constraints have to be dropped before dropping indexes and have to be recreated after the particular index(es) have been recreated.
This is a major issue right now for people trying to upgrade to DBAL 2.5.



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

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

Comment by Doctrine Bot [ 26/Dec/14 ]

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





[DBAL-1091] [GH-755] Update MysqliStatement to support PDO::FETCH_OBJ Created: 23/Dec/14  Updated: 04/Jan/15  Resolved: 04/Jan/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: driver, fetch, mysql, mysqli, object


 Description   

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

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

Message:

Return a simple stdClass object if that fetch type is requested.



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

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





[DBAL-1090] [GH-754] Changing string to fixed string is not recognized in PostgreSQL Platform Created: 21/Dec/14  Updated: 26/Dec/14  Resolved: 26/Dec/14

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

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


 Description   

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

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

Message:

The following change of an entity using PostgreSQL is not recognized by Doctrine DBAL:
from

    /**
     * @ORM\Column(type="string", name="name", length=2)
     */
    public $name;

to

    /**
     * @ORM\Column(type="string", name="name", length=2, options={"fixed"=true})
     */
    public $name;

A schema-update should change the column from `character varying(2)` to `character(2)` but instead acts like no changes were made on the column.

With this PR, I've extended the `PostgreSqlPlatform` to detect changes of the fixed option of a column.



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

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





[DBAL-1089] [GH-753] Add a unit test for broken backslashes on MySQL in LIKE Created: 19/Dec/14  Updated: 19/Dec/14

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

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


 Description   

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

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

Message:






[DBAL-1088] [GH-752] Fix error handling restore Created: 19/Dec/14  Updated: 31/Dec/14  Resolved: 31/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: connection, error, handler, mysqli


 Description   

This issue is created automatically through a Github pull request on behalf of nicolas-grekas:

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

Message:

PHP already handles an internal stack of error handlers



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

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

Comment by Doctrine Bot [ 31/Dec/14 ]

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





[DBAL-1087] [GH-751] Length of fixed string type (char) is ignored on Postgre schema update Created: 19/Dec/14  Updated: 31/Dec/14  Resolved: 31/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, postgresql, schemamanager


 Description   

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

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

Message:

This PR should fix an issue for the fixed string type columns using PostgreSQL.

I've created a basic Symfony 2.6. Application and using a PostgreSQL 9.3. database. In this dummy project, I've created the following Entity:

<?php

namespace Acme\DemoBundle\Entity;

use Doctrine\ORM\Mapping AS ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="test")
 */
class Test
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue
     */
    public $id;

    /**
     * @ORM\Column(type="string", name="name", length=2, options={"fixed" = true})
     */
    public $name;
}

The table is successfully created after a schema update, but when another schema update is executed without any changes to the entity, an ALTER query is executed:

ALTER TABLE test ALTER name TYPE CHAR(2);

After I searched in the code of doctrine dbal, I discovered that the length of the char column is not fetched correctly in `PostgreSqlSchemaManager::_getPortableTableColumnDefinition()`. In my example, length results as `null` and will be later set to 255 in the `Comparator`, which isn't the correct length from the database column. The comparation of the schemas results in a change of char-length.

For simplicity, I extended the if-condition in `PostgreSqlSchemaManager` to:

if (strtolower($tableColumn['type']) === 'varchar' || strtolower($tableColumn['type']) === 'bpchar') {

The fix I've contributed does help to parse the length in my case, but when I look into `PostgreSqlPlatform::initializeDoctrineTypeMappings()` there could be other types with the same problem, that are mapped to the doctrine string type.

// ... part of PostgreSqlPlatform::initializeDoctrineTypeMappings()
            'varchar'       => 'string',
            'interval'      => 'string',
            '_varchar'      => 'string',
            'char'          => 'string',
            'bpchar'        => 'string',
            'inet'          => 'string',

I guess we need to cover `char` and the others too.

`PostgreSqlSchemaManagerTest` also doesn't cover existing code. How is this going to be tested? Does the SchemaManagers need some tests in general?



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

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





[DBAL-1086] [GH-750] Store the parameters of the chosen connection when using Master/Slave. Created: 19/Dec/14  Updated: 04/Jan/15

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

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


 Description   

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

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

Message:

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

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

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

I also expanded the tests for this case.



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

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





[DBAL-1085] Custom Type Compare Fails To Generate Correct Migrations Created: 19/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0, 2.1, 2.2, 2.3, 2.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Vanheuverzwijn Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: migrations
Environment:

Everywhere



 Description   

// From doctrine 2.1
public function diffColumn(Column $column1, Column $column2)
{
$changedProperties = array();
if ( $column1->getType() != $column2->getType() )

{ $changedProperties[] = 'type'; }

...
}
The $column1->getType() will return the underlying platform object but the $column2->getType() will return the custom object type.

Because of the way the php compare function works, a custom type will always generate a changed property over the type of a column.

http://stackoverflow.com/questions/26964367/symfony2-doctrine-custom-types-generating-unneeded-migrations/27557785#27557785



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

Nicolas Vanheuverzwijn I think you will have to mark your custom type as requiring a SQL comment, otherwise the schema manager cannot distinguish between DateTime type and your custom type because both map to the same native SQL type. See here:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L327-L340

You will have to add the following to your custom type implementation:

/**
 * {@inheritdoc}
 */
public function requiresSQLCommentHint(AbstractPlatform $platform)
{
    return true;
}

Also I think it might be required to give your custom type a distinct name like:

/**
 * {@inheritdoc}
 */
public function getName()
{
    return 'datetime_utc';
}
Comment by Steve Müller [ 24/Dec/14 ]

See also: http://doctrine-orm.readthedocs.org/en/latest/cookbook/custom-mapping-types.html

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Wow, I shall take a look at this. This might be it ! Thanks a lot for your reply.

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

You're welcome. Can you please report if that fixed your problem so we can closse the issue eventually? Thanks.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

Yes sir. The problem I have was that I am using doctrine 2.2. I shall migrate my stuff to doctrine 2.5 and use that feature.

Comment by Nicolas Vanheuverzwijn [ 24/Dec/14 ]

This feature is implemented in version >=2.3 of Doctrine/DBAL.

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

Yes. 2.2 is EOL anyways and I think 2.3 is now only getting security fixes so an upgrade to at least 2.4 is highly recommended.





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

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

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

MySQL 5.6.4+



 Description   

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

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

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

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

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

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

Any thoughts on this?



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

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

Comment by Jachim Coudenys [ 19/Dec/14 ]

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

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

Jachim Coudenys can you please check if it fixes your issue if you adopted this:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SQLAnywherePlatform.php#L495-L501

to MysqlPlatform? Because it is basically the same issue. I currently don't have a MySQL 5.6 setup so I cannot test it on my machine.

Comment by Jachim Coudenys [ 31/Dec/14 ]

Steve Müller I think I tried that in the beginning, but normal fields threw errors. I will try it on a VM the following days.





[DBAL-1083] [GH-749] [DBAL-1082] Fix SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: ddl, decimal, float, mysql, unsinged

Issue Links:
Reference
relates to DBAL-1082 SchemaTool does not generate SQL for ... Resolved

 Description   

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

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

Message:



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

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





[DBAL-1082] SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Daniel Chesterton Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: dbal, ddl, decimal, float, mysql, schematool, unsigned
Environment:

MySQL


Issue Links:
Reference
is referenced by DBAL-1083 [GH-749] [DBAL-1082] Fix SchemaTool d... Resolved

 Description   

The schema update tool does not consider the possibility that MySQL double/float fields can be unsigned.

When running the CLI tool, it recognises that the schemas differ but it doesn't add the appropriate 'UNSIGNED' SQL statement. For example when the database is SIGNED but the entity is marked as UNSIGNED, running the tool with --dump-sql will generate SQL similar to below:

ALTER TABLE tablename CHANGE field field DOUBLE PRECISION NOT NULL;

Running this has no effect on the database and subsequent calls will try to run the same SQL.

I have created a pull request in GitHub which fixes the issue.






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

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

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

Windows



 Description   

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

My query looks like this:

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

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

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

I have registered new class Sum which extends FunctionNode.

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

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

The line :

ROW_NUMBER() OVER (ORDER BY value) DESC)

should look like

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

In doModifyLimitQuery method I have modified:

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

to:

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

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

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

Thanks in advance!



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

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

Comment by Maciej Grajcarek [ 17/Dec/14 ]

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

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

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

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

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

That doesn't involve the paginator, just DQL.

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

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

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

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

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

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

SQL Server do not support aliasing in OVER clause.

It should look like this, to work:

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

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

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

Maciej Grajcarek looks like it is an issue with your SUM function implementation. If you change your DQL to use ORDER BY COUNT(ypk.value) instead of ORDER BY SUM(ypk.value), does it work then? If so, there is something wrong with your SUM function and therefore not an issue with DBAL.

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

well forget about it I think I am wrong here.

Comment by Maciej Grajcarek [ 29/Dec/14 ]

Hi,
I will try to use COUNT as soon as I will be able to do that.

But I already tried other aggregation functions before and the result was exactly the same.





[DBAL-1080] [GH-748] minor phpdoc fixes in the remaining files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 19/Dec/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: code, cs, phpdoc, style

Issue Links:
Reference
relates to DBAL-1079 [GH-747] minor phpdoc fixes in the sc... Resolved

 Description   

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

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

Message:

This pr fixes the remaining phpcs issues left after #746 & #747



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

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





[DBAL-1079] [GH-747] minor phpdoc fixes in the schema files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: code, cs, phpdoc, style

Issue Links:
Reference
is referenced by DBAL-1080 [GH-748] minor phpdoc fixes in the re... Resolved

 Description   

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

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

Message:

Some minor phpcs fixes in the dbal schema files



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

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





[DBAL-1078] [GH-746] minor phpdoc fixes in the platform files Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 16/Dec/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: code, cs, docblock, style


 Description   

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

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

Message:

Some minor phpcs fixes in the dbal platform files



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

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DBAL-1077] Query limit for sql server Created: 16/Dec/14  Updated: 21/Feb/15

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

Type: Bug Priority: Major
Reporter: yannick LE LAN Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, regex, sqlserver
Environment:

sql server



 Description   

On branch master: tests/Doctrine/Tests/DBAL/platforms/AbstractSQLServerPlatformTestCase.php
On branch 2.4: tests/Doctrine/Tests/DBAL/platforms/SqlServerPlatformTest.php

public function testModifyLimitQueryFolcoerr()
{

    $sql = $this->_platform->modifyLimitQuery('SELECT son.label AS Name FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0 ORDER BY son.identifier DESC', 1, 0);

    $this->assertEquals('SELECT * FROM (SELECT son.label AS Name, ROW_NUMBER() OVER (ORDER BY son.identifier DESC) AS doctrine_rownum FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum', $sql);

}

Correction proposed:
on both branches: lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php

protected function doModifyLimitQuery(...)
{
    ...

    #ACTUAL: 
    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/i';

#CORRECT:

    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/iU';

explanation: "/U" pattern modifier => http://php.net/manual/en/reference.pcre.pattern.modifiers.php
Ungreedy behavior not susceptible to fall on ?! negative lookahead on parenthesis hunger

  1. has impacts on ORM with setMaxResults (which was failing in my case and made me investigate)


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

Can you send a PR for this change instead?

Comment by yannick LE LAN [ 16/Dec/14 ]

I will do so by the end of the week,

Comment by yannick LE LAN [ 21/Feb/15 ]

Pull requests made:

For dbal version 2.4:
https://github.com/doctrine/dbal/pull/803

For dbal master branch:
https://github.com/doctrine/dbal/pull/804

(as branch 2.4 seems to lack an 'order by' the patch had to be slightly different)





[DBAL-1076] [GH-745] Added doModifyLimitQuery for SQLServer2012Platform that uses OFFSET... FETCH Created: 16/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: limit, offset, orderby, server, sql, sqlserver, sqlsrv


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

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

This pull request:

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

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



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

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





[DBAL-1075] [GH-744] Removed non-phpdoc @internal tags Created: 15/Dec/14  Updated: 24/Dec/14  Resolved: 16/Dec/14

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

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


 Description   

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

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

Message:

Removed 2 @internal phpdoc tags as they were about old internal api usage and these methods are public api as @beberlei & @Ocramius confirmed on irc #doctrine

> ocramius: the @internal are old comments that were used to tell information about internal API usage
> ocramius: they are not the @internal of phpdoc, so you are welcome to send a PR to fix that



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

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DBAL-1074] [GH-743] Add failing unit test related to DBAL-1063 Created: 14/Dec/14  Updated: 03/Jan/15  Resolved: 03/Jan/15

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.5
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
is referenced by DBAL-1063 Exceptions from SchemaTool when runni... Resolved

 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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

Comment by Doctrine Bot [ 03/Jan/15 ]

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





[DBAL-1073] [GH-742] Take care about mariadb platform Created: 12/Dec/14  Updated: 24/Dec/14  Resolved: 24/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: detection, mariadb, mysql, platform, version


 Description   

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

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

Message:

Hi,
After upgrading to DBAL 2.5, I got an issue where I could not rename index while migrating because of MariaDB [versioning](http://en.wikipedia.org/wiki/MariaDB#Versioning) which outputs ```10.0.15-MariaDB-1~wheezy ``` as server version.

Because 10.x > 5.7 it loads new features from mysql 5.7 which are not available in mariadb ..



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

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

Comment by Doctrine Bot [ 24/Dec/14 ]

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





[DBAL-1072] [GH-741] [DBAL-1051] Quote index name in inline index declaration SQL Created: 12/Dec/14  Updated: 12/Dec/14  Resolved: 12/Dec/14

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

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

Issue Links:
Reference
relates to DBAL-1051 [GH-730] Update index name quoting in... Resolved

 Description   

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

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

Message:

Supersedes #730

  • Improved test case
  • Fixed quoting for SQL Anywhere
  • Throw exception in DB2 platform for unsupported inline index declarations


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

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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

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

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





[DBAL-1071] [GH-740] Add 2.5 status to README Created: 11/Dec/14  Updated: 24/Dec/14  Resolved: 11/Dec/14

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