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

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

Message:

Added support of maps a Doctrine datetimetz type to a MS SQL SERVER type datetimeoffset(6)

This issue is created automatically through a Github pull request on behalf of ananda-agrawal:

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

Message:

check $this->keepSlave before enforcing master as slave

>> var_dump(get_class($db));

string(24) "Doctrine\DBAL\Connection"

>> var_dump($params);

array(2)

>> $stmt = $db->executeQuery('SELECT l0_.id AS id0 FROM link l0_ WHERE l0_.user_id = ? AND l0_.is_deleted = ?', array($params), array(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY));

An exception occurred while executing 'SELECT l0_.id AS id0 FROM link l0_ WHERE l0_.user_id = ?, ? AND l0_.is_deleted = ?' with params [18, 0]: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

>> $stmt = $db->executeQuery('SELECT l0_.id AS id0 FROM link l0_ WHERE l0_.user_id = ? AND l0_.is_deleted = ?', $params, array(\PDO::PARAM_INT, \PDO::PARAM_INT));
>> var_dump($stmt->fetchAll());

array(0) {
}

Using PostgreSQL and column with "timestamp without time zone" returns datetime in format Y-m-d H:i:s.u but not always. If u is zero the PHP driver returns Y-m-d H:i:s format only. Specification of function getDateTimeFormatString is missing for this case too. It's required to resolve described different two formats and add getDateTimeFormatString with usec to postgres platform
It's similar as DBAL-397 but for not time zone datetimes. It throws the same exception as in linked issue.

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

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

Message:

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

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

Basically, following usage always throws an exception:

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

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

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

Message:

The main reason being to allow QueryBuilder to be subclassed ��� for example so that we can fix issues like problematic shallow cloning locally and use them without having to wait for a pull request to be merged.

Hello, i have got an error with doctrine 2.3.4 when i try to run the following code :

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

Error : Value for :bar not found in params array. Params array key should be "bar"

This code worked with doctrine 2.3.3.

I think the error comes from the function 'extractParam' in SQLParserUtils.php (DBAL)

line 215 : if (isset($paramsOrTypes[$paramName]))

The key exists even if the value is null.
So it should be:

  if (array_key_exists($paramName, $paramsOrTypes)) 

I am not enough confident to try a PR.
Thanks in advance!

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

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

Message:

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

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

Message:

while doing a transaction (as a result of ORM persist),
the connect function sets the forceMasterAsSlave which result on setting
slave to master,

on future selects, even if keepSlave is set to true
and connecting to 'slave' as ->connect('slave')
we will get master connections

I assume we need to check keepSlave when forcing slaves to master

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

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

Message:

Camel case methods names.

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

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

Message:

See http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html

As utf8mb4 is a superset of utf8, this should be transparent and backward compatible.
For those really requiring the "utf8" meant by MySQL, they can use explicitely the utf8mb3 charset.
But IMHO by default, Doctrine should really use utf8mb4, which is what everybody expect from a charset named "utf8".

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

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

Message:

Currently, the postgres dbal platform generates the following sql code for the substring function : `SUBSTR('foo', 1, 2)`
where in postgres, it should be :
`SUBSTRING('foo' FROM 1 FOR 2)`
This pull request simply fixes that issue.

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

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

Message:

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

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

Message:

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

https://api.github.com/repos/doctrine/dbal/zipball/2.3.4:

500: Internal Server Error

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

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

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

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

I have a Schema\Table with a column:

$usersTable->addColumn("lastip", "string", array("length" => 32, "default" => ""));

When I use Schema\Comparator on this table I get a ColumnDiff:

object(Doctrine\DBAL\Schema\ColumnDiff)[554]
  public 'oldColumnName' => string 'lastip' (length=6)
  public 'column' => 
    object(Doctrine\DBAL\Schema\Column)[481]
      protected '_type' => 
        object(Doctrine\DBAL\Types\StringType)[278]
      protected '_length' => int 32
      protected '_precision' => int 10
      protected '_scale' => int 0
      protected '_unsigned' => boolean false
      protected '_fixed' => boolean false
      protected '_notnull' => boolean true
      protected '_default' => string '' (length=0)
      protected '_autoincrement' => boolean false
      protected '_platformOptions' => 
        array
          empty
      protected '_columnDefinition' => null
      protected '_comment' => null
      protected '_customSchemaOptions' => 
        array
          empty
      protected '_name' => string 'lastip' (length=6)
      protected '_namespace' => null
      protected '_quoted' => boolean false
  public 'changedProperties' => 
    array
      0 => string 'default' (length=7)
  public 'fromColumn' => 
    object(Doctrine\DBAL\Schema\Column)[293]
      protected '_type' => 
        object(Doctrine\DBAL\Types\StringType)[278]
      protected '_length' => int 32
      protected '_precision' => int 10
      protected '_scale' => int 0
      protected '_unsigned' => boolean false
      protected '_fixed' => boolean false
      protected '_notnull' => boolean true
      protected '_default' => string '''::character varying' (length=21)
      protected '_autoincrement' => boolean false
      protected '_platformOptions' => 
        array
          empty
      protected '_columnDefinition' => null
      protected '_comment' => string '' (length=0)
      protected '_customSchemaOptions' => 
        array
          empty
      protected '_name' => string 'lastip' (length=6)
      protected '_namespace' => null
      protected '_quoted' => boolean false

With "default" postgresql adds "::character varying" when it's a varchar.

This gives a alter sql query:

ALTER TABLE bolt_users ALTER lastip SET  DEFAULT ''

After executing this, the next time it's the ColumnDiff again. Should the "::character varying" part be ignored by doctrine? Because then the schema will be valid.

Using Doctrine 2.4.0-BETA1 (38b1a340c5ec7c58be1883696c1f956bed5b7f0c)

I'm using doctrine with symfony. The first schema update is working, the table exists with all defined columns.
When i now run the schema update a second time (without code changes), doctrine tries to create the columns - but they already exists:

$ php app/console doctrine:schema:update --dump-sql
CREATE SEQUENCE users_id_seq INCREMENT BY 1 MINVALUE 1 START 1;
CREATE TABLE users (id INT NOT NULL, email VARCHAR(255) NOT NULL, password VARCHAR(255) DEFAULT NULL, salt VARCHAR(255) DEFAULT NULL, realname VARCHAR(255) NOT NULL, roles TEXT NOT NULL, PRIMARY KEY(id))
$ php app/console doctrine:schema:update --force
Updating database schema...
Database schema updated successfully! "2" queries were executed
$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE users ADD id INT NOT NULL;
ALTER TABLE users ADD email VARCHAR(255) NOT NULL;
ALTER TABLE users ADD password VARCHAR(255) DEFAULT NULL;
ALTER TABLE users ADD salt VARCHAR(255) DEFAULT NULL;
ALTER TABLE users ADD realname VARCHAR(255) NOT NULL;
ALTER TABLE users ADD roles TEXT NOT NULL;
ALTER TABLE users ADD PRIMARY KEY (id)

Doctrine seems to ignore existing columns.

PHPUnit segfaults because of a backslash prepended to a FQCN and has a failure in the tests run so far (see attached PHPUnit output).

in the method Doctrine\DBAL\Schema\MySqlSchemaManager::_getPortableTableColumnDefinition the index "comment" in the array $tableColumn is accessed without ensuring that this index is set. This leads to an Undefined index: comment warning in E_ALL-environments.

This method is triggered e.g. by the Doctrine\ORM\Tools\SchemaTool getUpdateSchemaSql method.

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

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

Message:

Current implementation of MasterSlaveConnection is very restrictive. The slave is picked up only when `executeQuery` is used. If appliacation uses `prepare` method in queries, every `SELECT` is done on master and this is bad for performance of master.

This PR changes how and when it picks the slave or master:

1. Slave if master was never picked before and ONLY if `getWrappedConnection`, `query`, `prepare`, or `executeQuery` is used and the query begins with `SELECT` (case insensitive) string.

2. Master picked when `exec`, `executeUpdate`, `insert`, `delete`, `update`, `createSavepoint`, `releaseSavepoint`, `beginTransaction`, `rollback`, `commit` is called.

3. Master picked when `query`, `prepare` or `executeQuery` is called and the query doesn't begin with `SELECT` (case insensitive) string.

4. If master was picked once during the lifetime of the connection it will always get picked afterwards.

5. One slave connection is randomly picked ONCE during a request.

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

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

Message:

Add getGuidExpression() to PostgreSqlPlatform so that UUID support
works properly

When using Doctrine ORM mapping fields like this:

/**

• @var integer
  *
• @ORM\Column(name="id", type="integer", nullable=false)
• @ORM\Id
• @ORM\GeneratedValue(strategy="IDENTITY")
• @ORM\SequenceGenerator(sequenceName="schemaname.tablename_id_seq", allocationSize=1, initialValue=1)
  */
  private $id;

It first creates the migration perfectly as a serial column with the correct schema.

However when making a new migration diff it generates DROP statements for every sequence for these id, so we have to remove them manually every time.

When using Custom Doctrine DBAL Enums the migration created using diff

works fine the first time.

However the next time it generates a SQL statement trying to change to field type to INT from integer; (Redundant)
and a truncated statement:

"ALTER schemaname.fieldname SET" .. And that's it.

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

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

Message:

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

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

Message:

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

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

Message:

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

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

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

Message:

This would allow, for example, to create some fulltext indexes with the MysqlPlatform, by passing the "fulltext" flag.

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

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

Message:

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

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

Message:

The regex used to replace the FROM clause was in a "starts with" form, which also matched column names that start with the word "FROM". This resulted in column names being replaced with the logic used for limiting, breaking the query once pagination is used. I added a whitespace requirement after "FROM' in the regex as well as a trailing whitespace in the replacement.

I am working with a table that has columns that start with the word "from" (fromNumber, fromCity, etc). When SQLServerPlatform->doModifyLimitQuery is called, "from" in the names are incorrectly replaced. I suggest adding a whitespace requirement after FROM in the preg_replace on this line:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php#L848

So this:

$query = preg_replace('/\sFROM/i', ", ROW_NUMBER() OVER ($over) AS doctrine_rownum FROM", $query);

Becomes this:

$query = preg_replace('/\sFROM\s/i', ", ROW_NUMBER() OVER ($over) AS doctrine_rownum FROM ", $query);

Since a few days we are seeing errors like this in the Jackalope Doctrine DBAL test suite when using prepared statements:
https://travis-ci.org/jackalope/jackalope-doctrine-dbal/jobs/6350278#L117

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

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

Message:

Fixed http://www.doctrine-project.org/jira/browse/DDC-2110. While selecting the configured search_path, ```"$user"``` is not replaced with the name of the current user. This commit will do the replacing.

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

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

Message:

Using the Schema\Comparator to diff a table in sqlite with a unsigned integer. When creating the table and comparing it with the same definition it gives a diff which is not expected:

 
$schema = new \Doctrine\DBAL\Schema\Schema();
$usersTable = $schema->createTable("test_users");
$usersTable->addColumn("id", "integer", array("unsigned" => true, 'autoincrement' => true));
$usersTable->setPrimaryKey(array("id"));
$usersTable->addColumn("username", "string", array("length" => 32));
$usersTable->addIndex( array( 'username' ) );
$usersTable->addColumn("password", "string", array("length" => 64));

$platform = new \Doctrine\DBAL\Platforms\SqlitePlatform();
$queries = $platform->getCreateTableSQL($usersTable);
foreach($queries as $query) {
    $conn->query($query);
}

$tableDetail = $sm->listTableDetails($usersTable->getName());
$comparator = new \Doctrine\DBAL\Schema\Comparator();
$diff = $comparator->diffTable($tableDetail, $usersTable);
if ($diff) {
    print(implode("\n",$platform->getAlterTableSQL($diff)));
} else {
    print("no diff");
}

Expect result:

 
no diff

Actual result:

 
DROP INDEX IDX_1F5D03E2F85E0677
CREATE TEMPORARY TABLE __temp__test_users AS SELECT id, username, password FROM test_users
DROP TABLE test_users
CREATE TABLE test_users (id INTEGER NOT NULL, username VARCHAR(32) NOT NULL, password VARCHAR(64) NOT NULL, PRIMARY KEY(id))
INSERT INTO test_users (id, username, password) SELECT id, username, password FROM __temp__test_users
DROP TABLE __temp__test_users
CREATE INDEX IDX_1F5D03E2F85E0677 ON test_users (username)

When setting unsigned to false everything works. Shouldn't Doctrine know unsigned is not supported in sqlite?

Starting with this https://github.com/doctrine/dbal/commit/b84cda24335207d4e60afc88fa161317d94b6370#diff-0 all foreign keys in non standard schema all always different, because table1 doesn't contain a schema name in it but table2 does.

It appears that attempting to run the Doctrine ORM test suite against an Oracle database causes the following exception:

[root@raymond-kolbe-1 orm]# /usr/local/zend/bin/phpunit -c oracle.xml
PHPUnit 3.7.19 by Sebastian Bergmann.

Configuration read from /home/rkolbe/sites/trainingv2/vendor/doctrine/orm/oracle.xml

......................SSSSSS...........................E

Time: 1 second, Memory: 68.75Mb

There was 1 error:

1) Doctrine\Tests\ORM\Functional\AdvancedAssociationTest::testIssue
Doctrine\DBAL\DBALException: An exception occurred while executing 'DROP USER rkolbe CASCADE':

ORA-01940: cannot drop a user that is currently connected

/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:47
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Statement.php:189
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php:112
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:791
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:816
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:306
/home/rkolbe/sites/trainingv2/vendor/doctrine/orm/tests/Doctrine/Tests/TestUtil.php:66
/home/rkolbe/sites/trainingv2/vendor/doctrine/orm/tests/Doctrine/Tests/OrmFunctionalTestCase.php:315
/home/rkolbe/sites/trainingv2/vendor/doctrine/orm/tests/Doctrine/Tests/ORM/Functional/AdvancedAssociationTest.php:17

Caused by
Doctrine\DBAL\Driver\OCI8\OCI8Exception: ORA-01940: cannot drop a user that is currently connected

/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Exception.php:28
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Statement.php:189
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php:112
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:791
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:816
/home/rkolbe/sites/trainingv2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:306
/home/rkolbe/sites/trainingv2/vendor/doctrine/orm/tests/Doctrine/Tests/TestUtil.php:66
/home/rkolbe/sites/trainingv2/vendor/doctrine/orm/tests/Doctrine/Tests/OrmFunctionalTestCase.php:315
/home/rkolbe/sites/trainingv2/vendor/doctrine/orm/tests/Doctrine/Tests/ORM/Functional/AdvancedAssociationTest.php:17

FAILURES!
Tests: 56, Assertions: 98, Errors: 1, Skipped: 6.

After investigating, I asked myself "Should Doctrine support dropping a "database"?" It should not, and here is why.

1) Oracle does not consider a "database" the same way MySQL and other vendors do. A "schema" is the database and this is the "user". Dropping a "database" drops the user. How would we recreate the database for testing purposes (read: DBAL drops and recreates the database)?

2) Oracle platform in DBAL does not support creating a database. Is this something we wish to support? I'm not sure how we would recreate a schema, since creating a schema is the same as creating a user. This is something we don't support on any platform. Also note, the return value of supportsCreateDropDatabase() is misleading as it says Oracle does support this feature.

Although this issue originated in Doctrine ORM, the root cause is the Oracle platform implementation in DBAL. I propose we remove support for dropping "databases" in Oracle since there is no way to create them.

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

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

Message:

When a query parameter contains binary data, `driverExceptionDuringQuery()` generates a PHP warning. This is because it internally uses `json_encode()`, which expects valid UTF-8 strings (at least in PHP 5.4.13).

This PR removes the warning with the `@` operator. `json_encode()` will still return a string representation, replacing the binary data with `null`.

I added a test that fails before the fix.

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

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

Message:

This PR introduces a real solution for the issues discussed in DBAL-374(http://www.doctrine-project.org/jira/browse/DBAL-374).
It adds the possibility to retrieve quoted column names from <code>Index</code> and <code>ForeignKeyConstraint</code> assets if it is necessary (e.g. column name is a keyword reserved by the platform).
In general column names are wrapped into an abstraction class <code>Identifier</code> which inherits from <code>AbstractAsset</code> inside <code>Index</code> and <code>ForeignKeyConstraint</code>. This allows to get a quoted representation of each column name via the <code>AbstractAsset::getQuotedName</code>.
All platforms are updated to make use of the new functionality.

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

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

Message:

When passing incomplete type information to `Connection::query()`, `SQLParserUtils` currently behaves the wrong way as it ignores all typing information instead falling back to a default (`PDO::PARAM_STR`). I don���t know this place very well, so please review carefully.

I'm getting the following error when I'm merely requesting schemaManager->listTables() on an SQLite DB with several columns set to 'integer unsigned'.

PHP Fatal error: Uncaught exception 'Doctrine\DBAL\DBALException' with message 'Unknown database type integer unsigned requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it.' in /..snip../vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php:321

$ sqlite3 --version
3.7.14.1

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

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

Message:

This PR improves listing table indexes in SQL Server. Currently table indexes are retrieved in the platform via a stored procedure <code>sp_helpindex</code> which causes problems with some SQL Server drivers like ODBC that cannot retrieve information from stored procedure calls. Table indexes are retrieved via native system tables now, which seems cleaner and is more flexible concerning which information to retrieve.
Additionally code duplication in <code>SQLServerSchemaManager::_getPortableTableIndexesList</code> is removed and simplified by this PR.

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

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

Message:

This PR fixes listing composite foreign keys in <code>SQLServerSchemaManager</code>. Currently the schema manager creates a foreign key object for each column in a foreign key constraint returned by the platform's <code>listTableForeignKeysSQL</code>, This is ok for foreign keys consisting of only one column but fails for composite foreign key constraints. The test <code>testListForeignKeysComposite</code> in <code>SQLServerSchemaManagerTest</code> currently fails but is fixed with this PR.

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

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

Message:

This PR fixes altering column default values. In SQL Server column default values are stored in constraints. <code>CREATE TABLE</code> statements with column declarations like <code>some_column NVARCHAR(50) NOT NULL DEFAULT 'default value'</code> internally creates a default constraint with an automatically generated name in the the system table `sys.default_constraints`. <code>ALTER TABLE</code> statements do not support the <code>DEFAULT</code> clause in column alteration declarations, leading in SQL syntax errors. Thus changing a column's default value is currently not possible.
To alter a column's default value, the old column's default constraint hast to be dropped and recreated again. As a default constraint has to be referenced by name to be dropped, we need to create each default constraint with an own unique name. This PR generates separate statements for default constraint declarations. It generates a unique name consisting of the table name and the column name the default constraint is created for.
<code>DF_TABLE_NAME_HASH%_%COLUMN_NAME_HASH%</code>

% ./bin/doctrine.php --env=development orm:schema-tool:update --dump-sql                                                                                                  
ALTER TABLE groups CHANGE active active TINYINT(1) DEFAULT '1' NOT NULL;
ALTER TABLE module ADD root_order INT DEFAULT 0 NOT NULL
% ./bin/doctrine.php --env=development orm:schema-tool:update --force
Updating database schema...
Database schema updated successfully! "2" queries were executed
% ./bin/doctrine.php --env=development orm:schema-tool:update --dump-sql                                                                                                  ALTER TABLE groups CHANGE active active TINYINT(1) DEFAULT '1' NOT NULL;
ALTER TABLE module CHANGE root_order root_order INT DEFAULT 0 NOT NULL

My entities define these columns like this:

    /**
     * @ORM\Column(name="active", type="boolean", options={"default":true})
     */
    private $active = true;

    /**
     * @ORM\Column(name="root_order", type="integer", options={"default":0})
     */
    private $rootOrder = 0;

When calculating table diffs, SQLServerSchemaManager returns column definitions for identity columns with _autoincrement set to FALSE.

This causes the schema update SQL generation to pump out a
ALTER TABLE x ALTER COLUMN id INT IDENTITY NOT NULL
for every single identity column in the schema.

The culprit is in DBAL\Schema\SQLServerSchemaManager, starting at line 43:

        $dbType = strtolower($tableColumn['TYPE_NAME']);
        $dbType = strtok($dbType, '(), ');

        $autoincrement = false;
        if (stripos($dbType, 'identity')) {
            $dbType = trim(str_ireplace('identity', '', $dbType));
            $autoincrement = true;
        }

When the column in question is an identity int column, the TYPE_NAME is "int identity". The second line of the snippet drops the "identity" signifier, causing the following lines that determine autoincrement to do nothing.

I simply moved the second line to below the autoincrement block ie:

        $dbType = strtolower($tableColumn['TYPE_NAME']);

        $autoincrement = false;
        if (stripos($dbType, 'identity')) {
            $dbType = trim(str_ireplace('identity', '', $dbType));
            $autoincrement = true;
        }

        $dbType = strtok($dbType, '(), ');

This change solves this issue for me, and as far as I can tell, has no other consequences.

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

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

Message:

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

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

Message:

In combination of PHP 5.4 and Doctrine 2 (upto 2.4Beta1) there's a bug with "boolean" type of field.
Ref link:��http://stackoverflow.com/questions/10242312/pdo-bindvalue-with-pdoparam-bool-causes-statement-execute-to-fail-silently

This patch binds int instead of bool and everything goes working fine.

I have changed a @ManyToOne relation to another entity. My workflow was this:

• Having @ManyToOne(targetEntity="Entity\EntityA") in the source
• Creating the database schema
• Changing @ManyToOne(targetEntity="Entity\EntityA") to @ManyToOne(targetEntity="Entity\EntityB")
• Calling doctrine orm:schema-tool:update

orm:schema-tool:update doesn't notice that and doesn't re-create the FK on MySQL and PostgreSQL (haven't tested others).

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

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

Message:

The functional <code>ModifyLimitQueryTest</code> makes false expectations about the query results. <code>LIMIT</code> queries without <code>ORDER BY</code> clause return non-deterministic results, therefore the test cannot make any expectations about which values are returned and in which order. You can only expect a certain number of results.
The test might still work on platforms like mysql when you assume results to be in an ascending order, because the database might put the results of a non-deterministic query in an ascending order by default. Still this is not reliable and not all vendors do that.
This PR changes the tests to have an ordered, deterministic results by default to have more reliable expectations. Also one test about a non-deterministic query was added, which just asserts the number of results returned.

Generation of any SQL command to the database (From entities or migration versions) does not quote all the reserved keywords (For example a fieldname `right`.

Simple fix that always works: double-quote dbname, schemaname and fieldname

e.g "dbsecurity"."userschema"."users" or "tblusers"

MySQL : use the ` sign.

e.g `security`.`users` or `tblusers` (No support for schemas since I last checked some time ago)

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

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

Message:

Some platforms currently do not remove a comment on a column on table alteration.
This PR fixes this. Also updated platform and functional schema tests for this.
Besides that <code>OraclePlatform</code> now does not generate a useless <code>ALTER TABLE MODIFY</code> SQL snippet when only the column comment has changed, as this is handled seperately through <code>COMMENT ON COLUMN</code> SQL statement.

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

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

Message:

This PR adds the driver and DBAL for SAP SQL Anywhere databases. It distinguishes between versions 10 and below (base <code>SQLAnywherePlatform</code>), 11 (<code>SQLAnywhere11Platform</code>) and 12 (<code>SQLAnywherer12Platform</code>), similar to Microsoft SQL Server.
Most of the functional tests pass but there are some exceptions:

• <code>DataAccessTest::testFetchAllWithTypes</code>
  <pre>
  Failed asserting that two strings are equal.
  • • Expected
      +++ Actual
      @@ @@
      -'2010-01-01 10:10:10'
      +'2010-01-01 10:10:10.000'
      </pre>
      The test is not aware of the datetime format string of the platform, which differs in SQL Anywhere. Therefore it fails. In SQL Anywhere a datetime is stored with second fractions by default.
      IMO I have two options here. Changing the default timestamp format for data output in the driver on every connection so that it fits <code>Y-m-d H:i:s</code> and changing the date format strings in the platforms or modifying the test to be aware of the platform specific datetime format.

• <code>MasterSlaveConnectionTest::testKeepSlaveBeginTransactionStaysOnMaster</code>
  The test simply hangs up here and I don't exactly know why. When I change the value for insert in line 95 to some other value than 30 it perfectly works. Any help would be appreciated here.

• <code>ModifyLimitQueryTest::testModifyLimitQueryGroupBy</code>
  <pre>
  Failed asserting that two arrays are equal.
  • • Expected
      +++ Actual
      @@ @@
      Array (
  • 0 => 1
  • 1 => 2
    ++ 0 => 2
    ++ 1 => 1
    )
    </pre>
    The test does not tell the SELECT statement to order the result, thus the result is not deterministic and returns the results in wrong order.
    IMO the test should be fixed so that the result is ordered correctly. Then the test will pass for SQL Anywhere.

• <code>TemporaryTableTest</code>
  <pre>Exception: [Doctrine\DBAL\DBALException] An exception occurred while executing 'CREATE GLOBAL TEMPORARY TABLE temporary (id INT NOT NULL)':
  SQLSTATE [42W04] [-131] Syntaxfehler bei 'temporary' in Zeile 1
  With queries:
  SQL: 'DROP TABLE temporary' Params:
  SQL: 'CREATE GLOBAL TEMPORARY TABLE temporary (id INT NOT NULL)' Params:
  SQL: 'DROP TABLE nontemporary' Params:</pre>
  The tests use the unquoted keyword "temporary" reserved by SQL Anywhere for the temporary table name to create.
  I cannot quote the name of the temporary table in the platform as the method <code>getTemporaryTableName</code> expects a string and not an instance of <code>Doctrine\DBAL\Schema\Table</code> as parameter.
  Either the tests should use a non reserved keyword as temporary table name or the temporary table name has to be quoted in the platform (but I don't know exactly how).

• <code>TemporaryTableTest::testDropTemporaryTableNotAutoCommitTransaction</code>
  <pre>In an event of an error this result has one row, because of an implicit commit.
  Failed asserting that two arrays are equal.
  • • Expected
      +++ Actual
      @@ @@
      Array (
      ++ 0 => Array (...)
      )
      </pre>
      The test fails because of an implicit commit during the transaction (drop temporary table) which inserts the first value. I couldn't find a solution for this problem. Seems to be the same problem as reported in DDC-1337(http://www.doctrine-project.org/jira/browse/DDC-1337).

• <code>WriteTest::testLastInsertIdNoSequenceGiven</code>
  <pre>Failed asserting that 14 is false.</pre>
  I don't exactly know why the test expects the lastInsertId to be false here. Using the same connection for 14 inserts into a newly created autoincrement table should result in lastInsertId = 14 IMO. Is this a bug in the test? How do other vendors behave here?

I hope this addition is appreciated and any feedback/help on the above issues would be welcomed.

Dear Symfony team,

the filterExpression on AbstractSchemaManager seems not to work for sequences.

This only happens under postgres.

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

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

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

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

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

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

Message:

When updating the nullable status of a column the sql generated is

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) DEFAULT NULL)

This will set the default column value to null but does not modify the nullable status of the column. The correct sql would be

ALTER TABLE MET MODIFY (METAR VARCHAR2(2000) NULL)

The field definition changed from

metar:
type: string
length: 2000
nullable: false
column: METAR

to

metar:
type: string
length: 2000
nullable: true
column: METAR

I am not sure this is a correct posting to your issue tracker, as I am a beginner at development, at least in the sense of doctrine.

I have an entity named Trigger in my Symfony2 project. I had set the table name to be "trigger", and this did not work. However, the entities were created without any problems, I first discovered the problem when attempting to persist a Trigger entity. The solution was to rename the table to "mtrigger" or something else, but I think the error message could be better somehow. Now it throws an exception with the MySQL error, which only says there's an error in the syntax, and to check the manual. The manual is quite huge and it was a horror for me before I started thinking in the field of reserved words.

Note that this is just a proposal to an improvement. It might be that it is hard to implement it for you. In that case, please just close the issue.

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

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

Message:

This PR optimizes the <code>AbstractPlatform</code> class in the following ways:

• Add dedicated use statemtent for each class import
• Add missing class imports
• Add missing phpDoc blocks for methods
• Fix existing phpDocs (parameters, return types, @throws tags, FQDN types, indentation etc.)
• "Normalize" phpDocs (consistent verbs for what a method does, reuse of certain phrases for similar method types etc.)
• Fix CS
• Improve certain code portions

I hope this is a welcomed improvement. It reads much better now and feels somewhat cleaner to me.

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

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

Message:

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

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

Message:

Column cache wasn't working because the emptied flag is only set
when fetch no longer returns a row. With fetch column the code
only calls fetch once and so emptied flag never got set.

Created two test cases, one to test fetchColumn, and one to test
that the return value is false if the data doesn't get saved in the cache.

The problem I am having is with how the DateTimeType converts the DateTime field from sql svr. It seems to need different formats in the ::getDateTimeFormatString() depending in if you are converting from the database to PHP or the other way.

The method format 'Y-m-d H:i:s.000' that is there now works if the database is only written to with PHP, and not anything else.

In my case I am sharing access with other technologies. So basically when converting from the Database to PHP the format needs to be 'Y-m-d H:i:s.u' and 'Y-m-d H:i:s.000' when converting the other way.

If there functions convertToDatabaseValue() and convertToPHPValue() where in the Platform, then I could override these with my own custom platform and I would be right.

Otherwise to do this right we need to split this up getDateTimeFormatString() into 2 different methods, 1 for the database, and 1 for php.

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

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

Message:

Creating foreign key constraints via <code>getCreateConstraintSQL</code> in the platform doesn't quote the foreign table name leading to invalid SQL when the foreign table name is a reserved keyword. This PR fixes this issue.

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

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

Message:

The ResultCacheStatement has a small logic error, it tested for emptied
being true when it should have tested for emptied being false. The
comments also statement that the function returns a boolean, however the
function didn't return a boolean.

This is my first time committing to a larger open source project like dbal. Very worried I'll of done something wrong, please go easy / teach me.

When an update of schema tries to drop a primary key with "auto increment" property (example : @ORM\GeneratedValue(strategy="AUTO")), the execution will fail : it say :
[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE odesadicola DROP PRIMARY KEY':

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

Apparently, this error occurs because Doctrine try to execute a "drop primary key" on a table and the resulting column of old primary key will be "auto increment".

The answer is to remove "auto increment" attribut of primary key column juste before try to drop the primary key itself.

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

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

Message:

Added driver pdo_ibmi to support to db2 iSeries using pdo_odbc

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

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

Message:

Doc incorrectly makes a call to close(), when it should be calling closeCursor()

This issue occurred when I tried to create entities from existing MSSQL Database. My database have several fields that are defined as "numeric" data types. When I tried to reverse engineer this data base, doctrine threw an error mentioning that doctrine numeric data types are not supported. I have attached code that I used to create entities. And error that was generated. Hope this Helps narrow down the process. One thing that ca in to notice was that the "SQLServerSchemaManager" class does not have any specific mechanism to handle "numeric" as compared to "MySqlSchemaManager".

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

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

Message:

This PR fixes a bug in the <code>SchemaManagerFunctionalTestCase</code> composite foreign keys test I encountered today. In SQL Server the test case fails because both <code>testListForeignKeys</code> and <code>testListForeignKeysComposite</code> tests create a foreign key with the same name which is not possible for one single DB in SQL Server.
I don't know if this applies to other RDBMS also but this should also fix the others.