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

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

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


 Description   

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

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

Message:

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

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

Basically, following usage always throws an exception:

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


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

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





[DBAL-523] [GH-321] Changed property visibility to protected Created: 20/May/13  Updated: 20/May/13  Resolved: 20/May/13

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

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


 Description   

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.



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

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

Comment by Marco Pivetta [ 20/May/13 ]

Enforces BC on the internals of the QueryBuilder, which is a no-go given the complexity of the QueryBuilder itself





[DBAL-522] BC break : executeQuery with an array containing null value(s). Created: 20/May/13  Updated: 21/May/13  Resolved: 21/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: 2.4, 2.3.5

Type: Bug Priority: Blocker
Reporter: lemeunier Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dbal
Environment:

Mac OSX 10.8.3, Mysql 5.5.28, PHP5.4



 Description   

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!



 Comments   
Comment by Marco Pivetta [ 20/May/13 ]

I suggested a hotfix at https://github.com/doctrine/dbal/pull/322

Comment by lemeunier [ 21/May/13 ]

Thanks for the hotfix.





[DBAL-521] [GH-320] Fixed calculation of differences of columns Created: 17/May/13  Updated: 17/May/13

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

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


 Description   

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

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

Message:






[DBAL-520] [GH-319] Delete unnecessary "use PDO" statement Created: 16/May/13  Updated: 16/May/13

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

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


 Description   

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

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

Message:






[DBAL-519] MasterSlave connection does not keep Slave connections when there is a transaction Created: 15/May/13  Updated: 15/May/13

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

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


 Description   

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






[DBAL-518] [GH-318] Update Type.php Created: 15/May/13  Updated: 17/May/13  Resolved: 17/May/13

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

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


 Description   

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.



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

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





[DBAL-517] [GH-317] Conditionaly upgrade utf8 to utf8mb4 for MySQL 5.5.3 Created: 15/May/13  Updated: 15/May/13

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

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


 Description   

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






[DBAL-516] [GH-316] Fixed generated sql for postgres substring function Created: 15/May/13  Updated: 15/May/13  Resolved: 15/May/13

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

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


 Description   

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.



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

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

Comment by Marco Pivetta [ 15/May/13 ]

merged





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

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 14/May/13 ]

merged





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

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

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


 Description   

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

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

Message:

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



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

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

Comment by Marco Pivetta [ 14/May/13 ]

merged





[DBAL-513] downloading from github Created: 12/May/13  Updated: 12/May/13  Resolved: 12/May/13

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

Type: Bug Priority: Blocker
Reporter: Maarten Bogaert Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

500: Internal Server Error



 Comments   
Comment by Maarten Bogaert [ 12/May/13 ]

ok never mind, after a while the problem resolved itself and the zipball can be downloaded again





[DBAL-512] Update schema not working on MsSql due to no support for alter identity Created: 06/May/13  Updated: 06/May/13

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

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

Symfony 2.1, SQL Server 2008, driver: pdo_sqlsrv



 Description   

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

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

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

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






[DBAL-511] Schema\ColumnDiff incorrect with default varchar value and postgresql Created: 01/May/13  Updated: 04/May/13  Resolved: 04/May/13

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

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

Ubuntu 12.04.2 LTS
PHP 5.3.10-1ubuntu3.6
PostgreSQL(libpq) Version => 9.1.8



 Description   

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)



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of DBAL-483

Comment by Richard Hinkamp [ 02/May/13 ]

Hmm that's not a duplicate. The default column handling works great in mysql, sqlite and with integer/date/etc fields in postgres, just not with varchar and postgres. I think doctrine should handle the "::character varying" part which postgres adds to the default value of a varchar field.

Comment by Benjamin Eberlei [ 04/May/13 ]

Yes you are right, fixed the underlying issue now.





[DBAL-510] Schema tool does not recognize existing columns Created: 31/Oct/12  Updated: 01/May/13  Resolved: 01/May/13

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

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

Ubuntu 8.04 with PHP 5.3.2 and PostgreSQL 8.4/9.1 (errors on both versions)


Attachments: Text File phpunit_with_tap.txt    

 Description   

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).



 Comments   
Comment by Benjamin Eberlei [ 06/Jan/13 ]

Can i see your entity definition? This works normally, there must be something different in your environment.

Comment by Matthias Lohr [ 06/Jan/13 ]

I have the same problem in another project, so i'll give you the definitions from there. Here's the console output.

$ php -v
PHP 5.3.10-1ubuntu3.4 with Suhosin-Patch (cli) (built: Sep 12 2012 18:59:41) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

$ psql --version
psql (PostgreSQL) 9.1.7
contains support for command-line editing

$ php app/console doctrine:schema:update --dump-sql
CREATE TABLE invoices (id INT NOT NULL, number VARCHAR(255) NOT NULL, PRIMARY KEY(id));
CREATE TABLE items (id INT NOT NULL, label VARCHAR(255) NOT NULL, price DOUBLE PRECISION DEFAULT NULL, withTax BOOLEAN NOT NULL, PRIMARY KEY(id));
CREATE TABLE clients (id INT NOT NULL, label VARCHAR(255) NOT NULL, PRIMARY KEY(id))

$ php app/console doctrine:schema:update --force
Updating database schema...
Database schema updated successfully! "3" queries were executed

$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE invoices ADD id INT NOT NULL;
ALTER TABLE invoices ADD number VARCHAR(255) NOT NULL;
ALTER TABLE invoices ADD PRIMARY KEY (id);
ALTER TABLE items ADD id INT NOT NULL;
ALTER TABLE items ADD label VARCHAR(255) NOT NULL;
ALTER TABLE items ADD price DOUBLE PRECISION DEFAULT NULL;
ALTER TABLE items ADD withTax BOOLEAN NOT NULL;
ALTER TABLE items ADD PRIMARY KEY (id);
ALTER TABLE clients ADD id INT NOT NULL;
ALTER TABLE clients ADD label VARCHAR(255) NOT NULL;
ALTER TABLE clients ADD PRIMARY KEY (id)

$ php app/console doctrine:schema:update --force
Updating database schema...
                                                                   
  [Doctrine\DBAL\DBALException]                                                                   
  An exception occurred while executing 'ALTER TABLE invoices ADD id INT NOT NULL':               
                                                                                                  
  SQLSTATE[42701]: Duplicate column: 7 ERROR:  column "id" of relation "invoices" already exists  
                                                                                                  
                                                                                      
  [PDOException]                                                                                  
  SQLSTATE[42701]: Duplicate column: 7 ERROR:  column "id" of relation "invoices" already exists  
Client.php
<?php

namespace LohrTec\PureInvoiceBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="clients")
 */
class Client {

	/**
	 * client id
	 *
	 * @ORM\Id
	 * @ORM\Column(type="integer")
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var int
	 */
	private $id;

	/**
	 * client label
	 *
	 * @ORM\Column(type="string")
	 * @var string
	 */
	private $label;


	public function getId() {
		return $this->id;
	}

	public function getLabel() {
		return $this->label;
	}

	public function setLabel($label) {
		$this->label = $label;
	}

}
Invoice.php
<?php

namespace LohrTec\PureInvoiceBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="invoices")
 */
class Invoice {

	/**
	 * client id
	 *
	 * @ORM\Id
	 * @ORM\Column(type="integer")
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var int
	 */
	private $id;

	/**
	 * invoice number
	 *
	 * @ORM\Column(type="string")
	 * @var string
	 */
	private $number;

}
Item.php
<?php

namespace LohrTec\PureInvoiceBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="items")
 */
class Item {

	/**
	 * item id
	 *
	 * @ORM\Id
	 * @ORM\Column(type="integer")
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var int
	 */
	private $id;

	/**
	 * item label
	 *
	 * @ORM\Column(type="string")
	 * @var string
	 */
	private $label = '';

	/**
	 * item default price
	 *
	 * @ORM\Column(type="float", nullable=true)
	 * @var float
	 */
	private $price = null;

	/**
	 * false: pre tax price, true: post tax price
	 *
	 * @ORM\Column(type="boolean")
	 * @var boolean
	 */
	private $withTax = 1;

	public function __construct($label, $price = null, $withTax = null) {
		$this->setLabel($label);
		$this->setPrice($price, $withTax);
	}

	public function getId() {
		return $this->id;
	}

	public function getLabel() {
		return $this->label;
	}

	public function getPrice() {
		return $this->price;
	}

	public function priceIsTaxed() {
		return $this->withTax;
	}

	public function setLabel($label) {
		$this->label = $label;
	}

	public function setPrice($price, $withTax = null) {
		$this->price = $price;
		if ($withTax !== null) $this->withTax = ($withTax?true:false);
	}

	public function setPriceIsTaxed($isTaxed) {
		$this->withTax = $isTaxed;
	}

}
Comment by Adrien Brault [ 15/Apr/13 ]

This happens when the schema in which your tables are, is the first one in the list of `show search_path;`.
A simple workaround I'm using is to add a dumb schema at the beginning of search_path `ALTER USER youruser SET search_path = foo,yourschema,public;`.

Comment by Adrien Brault [ 15/Apr/13 ]

FYI, \Doctrine\DBAL\Platforms\PostgreSqlPlatform::getTableWhereClause doesnt seem to work when the $table has no "." in it. (Which happen when the schema is the first in the search_path ...).

Comment by Matthias Lohr [ 15/Apr/13 ]

Hey, thank you very much for for your information!

Comment by Matthias Lohr [ 15/Apr/13 ]

Ok, it's not the problem with the position of your schema, but the default schema is "$user" and that seems not to be parsed/replaced with the username! 'ALTER USER youruser SET search_path TO yoursearchpath, public;' works for me.

Comment by Matthias Lohr [ 15/Apr/13 ]

Fixed it (https://github.com/doctrine/dbal/pull/305).





[DBAL-508] MySqlSchemaManager accessing undefined index tableColumn[comment] Created: 30/Apr/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.3
Fix Version/s: 2.4

Type: Bug Priority: Trivial
Reporter: Martin Kuckert Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux 3.2.0-24-generic-pae #39-Ubuntu,
mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (i686) using readline 6.2



 Description   

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.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Can't really explain this, the key has to be existant. This is only called with information from MysqlPlatform#getListTableColumnsSQL().

Comment by Martin Kuckert [ 02/May/13 ]

I've just found the issue. The main problem is the usage of 'DESCRIBE ' . $table; in the getListTableColumnsSQL, if there's no $database set. describe does not return the comment column, but 'show full columns from ' . $table; does.
At the basis of the missing $database value was my own DBAL\Driver implementation not properly returning the currently connected database. So $database was NULL and the alternate code path was executed, so resulting in no comment-property.

Seems like an uncovered code path instead of a bug in a real environment.

Comment by Benjamin Eberlei [ 09/May/13 ]

Special case fixed for 2.4





[DBAL-507] [GH-313] Enhanced Master-Slave Connection Created: 26/Apr/13  Updated: 27/Apr/13  Resolved: 27/Apr/13

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

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


 Description   

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

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

Message:

Q A
-------------
Bug fix? no
New feature? yes
BC breaks? no?
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT

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.



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

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





[DBAL-506] [GH-312] [DBAL-264] Support for UIDs in PostgreSQL Created: 25/Apr/13  Updated: 27/Apr/13  Resolved: 27/Apr/13

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

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


 Description   

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

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

Message:

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



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

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





[DBAL-505] Issue whenusing serial columns in PostgreSQL Created: 24/Apr/13  Updated: 24/Apr/13

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

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PostgreSQL



 Description   

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.






[DBAL-504] DBAL Enum fields migration issue / PostgreSQL Created: 24/Apr/13  Updated: 06/May/13

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.3.3
Fix Version/s: None
Security Level: All

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

postgresql


Issue Links:
Duplicate
is duplicated by DDC-2238 doctrine:schema:update partially broken Resolved

 Description   

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.



 Comments   
Comment by Tom Vogt [ 01/May/13 ]

Doesn't only happen on Enums. I don't use any enums and I have this problem. I use a couple of geo (postGIS) fields (point, linestring, polygon) as well as array fields, so either or all of those might be causing it, too.

Comment by Benjamin Eberlei [ 04/May/13 ]

We did some changes for PostgreSQL column diffs lately, can you verify this bug still exists on the 2.3 Branch of DBAL?

Comment by Tom Vogt [ 06/May/13 ]

I'm running this on Symfony2 with this composer.json config:

"doctrine/orm": "2.3.*",
"doctrine/doctrine-bundle": ">=2.1",

and I'm still getting this issue today.





[DBAL-503] [GH-311] [WIP] Fixed CS Created: 23/Apr/13  Updated: 27/Apr/13  Resolved: 27/Apr/13

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: Benjamin Eberlei
Resolution: Invalid 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/311

Message:



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

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





[DBAL-502] [GH-310] fix function name in exception text Created: 23/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 23/Apr/13 ]

merged





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

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

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


 Description   

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

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

Message:

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



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

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





[DBAL-500] [GH-308] added index flags to schema table Created: 20/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

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

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


 Description   

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



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

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





[DBAL-499] [GH-307] Postgres fix for a possible unavailable dbname Created: 19/Apr/13  Updated: 04/May/13  Resolved: 04/May/13

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

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


 Description   

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

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

Message:



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

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





[DBAL-498] [GH-306] [DBAL-497] Fixed SQL Server platform replacing 'FROM' in column names during limit Created: 18/Apr/13  Updated: 20/Apr/13  Resolved: 18/Apr/13

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

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


 Description   

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



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

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

Comment by Marco Pivetta [ 18/Apr/13 ]

merged





[DBAL-497] SQLServerPlatform modifies limit query incorrectly when column names start with "from" Created: 18/Apr/13  Updated: 20/Apr/13  Resolved: 20/Apr/13

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

Type: Bug Priority: Major
Reporter: Shane Neuerburg Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: sqlserver
Environment:

OS X using FreeTDS driver, unixODBC
SQL Server 2008



 Description   

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);


 Comments   
Comment by Shane Neuerburg [ 18/Apr/13 ]

Pull request:
https://github.com/doctrine/dbal/pull/306





[DBAL-496] "Undefined index" errors when using prepared statements Created: 16/Apr/13  Updated: 21/Apr/13  Resolved: 20/Apr/13

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

Type: Bug Priority: Blocker
Reporter: Lukas Kahwe Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by Marco Pivetta [ 16/Apr/13 ]

First failure I can see is at https://travis-ci.org/jackalope/jackalope-doctrine-dbal/jobs/6347501 - is there any other relevant failure before that one?

Comment by Marco Pivetta [ 16/Apr/13 ]

The notice is thrown in in

Doctrine\DBAL\SQLParserUtils::expandListParameters

Can be reproduced with parameters:

$query:

UPDATE phpcr_nodes SET sort_order = CASE CONCAT(
          namespace,
          (CASE namespace WHEN '' THEN '' ELSE ':' END),
          local_name
        ) WHEN :name0 THEN :order0 WHEN :name1 THEN :order1 WHEN :name2 THEN :order2 WHEN :name3 THEN :order3 WHEN :name4 THEN :order4 ELSE sort_order END WHERE parent = :absPath

$params:

array(
    ':absPath' => '/topic',
    ':name0' => 'page3',
    ':order0' => 0,
    ':name1' => 'page1',
    ':order1' => 1,
    ':name2' => 'page2',
    ':order2' => 2,
    ':name3' => 'page3',
    ':order3' => 3,
    ':name4' => 'page4',
    ':order4' => 4,
)

$types:

array()
Comment by David Buchmann [ 17/Apr/13 ]

are we doing something wrong or is this a regression in dbal?

should we for now force an older version of doctrine-dbal? (this would be annyoing however, as we would run into version conflicts with doctrine-commons then i think)

Comment by Daniel Leech [ 17/Apr/13 ]

Seems this is caused by: https://github.com/doctrine/dbal/commit/64647f9e55749147b738cdba9378fa0401fadcbf

Comment by Fabio B. Silva [ 18/Apr/13 ]

I think the problem here is the ':' on the parameter key, which i'm not sure if are suported for DBAL.
Before #DBAL-488 it does not apply 'SQLParserUtils::expandListParameters' for parameters without types.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Reverted in master and 2.3

Comment by Fabio B. Silva [ 20/Apr/13 ]

Benjamin, Not sure if we should consider this one related to #DBAL-488.
It just show us another unsupported/unexpected behavior.

Actually, it will keep failing with any parameter key starting with ':' when types are given.

For instance :

$query:

SELECT * FROM foo WHERE bar = :bar

$params:

array(':bar'=>'Some String')

$types:

array(':bar'=>\PDO::PARAM_STR)
Comment by Lars Strojny [ 21/Apr/13 ]

Here is a successor for the fix from PR 301, @Fabio, could you test that with your code base: https://github.com/doctrine/dbal/pull/309





[DBAL-495] [GH-305] [DDC-2110] fixed problem with existing columns (postgresql) Created: 15/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

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

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


 Description   

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



 Comments   
Comment by Matthias Lohr [ 15/Apr/13 ]

This is a pull request for a fix for DDC-2110.

Comment by Doctrine Bot [ 01/May/13 ]

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





[DBAL-494] [GH-304] Fix for DBAL-442 Created: 14/Apr/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

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


 Description   

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

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

Message:



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

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





[DBAL-493] Schema\Comparator incorrect diff with sqlite and unsigned integer Created: 12/Apr/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

Type: Bug Priority: Major
Reporter: Richard Hinkamp Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

php 5.3.10-1ubuntu3.6
SQLite Library => 3.7.9



 Description   

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:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
 
$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?



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

SQLite doesn't have the notion of unsigned. You have to remote the "unsigned" => true flag to stop confusing Sqlite and the Comparision and it will work.





[DBAL-492] Foreign keys always changed with postgres non standard schema. Created: 11/Apr/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.3.2, 2.3.3
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Mārtiņš Šulcs Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

postgres



 Description   

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.



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

Fixed and waiting in 2.3 release branch for next mini





[DBAL-491] Oracle platform should not support dropping database Created: 10/Apr/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

Type: Bug Priority: Major
Reporter: Raymond Kolbe Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

RHEL w/Oracle



 Description   

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.



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

That is why you have to have two users configured in the phpunit.xml, the temporary user deletes the first user and recreates him. This works perfectly fine for us. I am not sure we should remove this.

Comment by Benjamin Eberlei [ 14/Apr/13 ]

Closing as won't fix, anything else is an enhancement, depends on the arguments for removing this approach





[DBAL-490] [GH-303] Fixed a PHP warning in DBALException::driverExceptionDuringQuery() Created: 09/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

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

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


 Description   

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



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

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





[DBAL-489] [GH-302] [DBAL-374] Fix asset identfier quotation Created: 08/Apr/13  Updated: 01/May/13

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

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


 Description   

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.






[DBAL-488] [GH-301] Fixing issue when number of positional parameters != number of given types Created: 08/Apr/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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.



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

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





[DBAL-487] DBAL's SqlitePlatform does not allow for fields of type 'integer unsigned'. Whether they exist already or not. Created: 05/Apr/13  Updated: 20/Apr/13  Resolved: 20/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.3
Fix Version/s: 2.3.4

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


 Description   

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



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

Fixed





[DBAL-486] [GH-300] Improve list SQL Server table indexes Created: 04/Apr/13  Updated: 06/Apr/13  Resolved: 06/Apr/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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.



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

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





[DBAL-485] [GH-299] Fix list SQL Server composite foreign keys Created: 04/Apr/13  Updated: 06/Apr/13  Resolved: 06/Apr/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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.



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

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





[DBAL-484] [GH-298] Fix SQL Server default constraints Created: 04/Apr/13  Updated: 06/Apr/13  Resolved: 06/Apr/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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>



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

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





[DBAL-483] default values make orm:validate-schema fail Created: 04/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

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

Type: Bug Priority: Major
Reporter: Till Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: schematool
Environment:

MySQL, PHP 5.3, Doctrine 2.3



 Description   
% ./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:

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


 Comments   
Comment by Felix Kaser [ 30/Apr/13 ]

We are having the same issue. Is there any workaround for this?

Comment by Felix Kaser [ 30/Apr/13 ]

I've investigated a bit and noticed several things:

  • looks like doctrine does not (officially?) support setting of default options in the annotation. It is recommended to use the instance default ($rootOrder = 0).
  • in the comparator class the Column->getDefault() is compared, but I found out that in one table (I guess the one from mysql) the default is set directly, in the other one (I guess the doctrine one generated from the annotations) the default is empty but the customSchemaOptions["default"] is set.

So based on this I would say:

  • the $column->getDefault needs to be checked against the other $column->getCustomSchemaOption("default") and vice versa

Please correct me if I'm wrong





[DBAL-482] SQL Server Schema Manager returns incorrect value for autoincrement on IDENTITY columns Created: 03/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.2, 2.3, 2.3.3
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Minor
Reporter: William Schaller Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: schematool, sqlserver, sqlsrv
Environment:

SQL Server



 Description   

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.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed for 2.3.4 and was fixed for 2.4 in a different way already.





[DBAL-481] [GH-297] check for proper type when formatting dates Created: 02/Apr/13  Updated: 02/Apr/13  Resolved: 02/Apr/13

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

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


 Description   

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

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

Message:



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

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





[DBAL-480] [GH-296] PDO bug workaround Created: 02/Apr/13  Updated: 09/May/13  Resolved: 09/May/13

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

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


 Description   

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



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

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

Comment by Benjamin Eberlei [ 09/May/13 ]

Not fixing PHP bugs or adding workarounds.

You need to pass an integer (1 or 0) instead of a boolean to make it working. This is how we do it in the ORM.





[DBAL-479] Doctrine2 schema-tool:update doesn't re-create foreign keys on entity change Created: 07/Jan/12  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

Type: Bug Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1585 Doctrine2 doesn't check for the corre... Resolved

 Description   

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).



 Comments   
Comment by Benjamin Eberlei [ 09/Jan/12 ]

Does this use the same variable or does the many to one variable name change?

Comment by Timo A. Hummel [ 09/Jan/12 ]

Yes, same variable name. For the real-world change, see:

https://github.com/partkeepr/PartKeepr/commit/1cf520f6433dd4d14785a7791a6efe6ab67cc47c

Comment by Timo A. Hummel [ 27/May/12 ]

Any news of this issue?

This is actually not a duplicate of DDC-1585.

Comment by Timo A. Hummel [ 27/May/12 ]

13:32:46 < beberlei> it is a DBAL issue, so you should start replicating it there
13:33:10 < beberlei> i mean, have a look at how the DBAL SchemaDiff looks like in that case, and why it creates the sql wrong
13:33:19 < beberlei> probably the comperator misses something

Comment by Timo A. Hummel [ 29/May/12 ]

I finally found the spot where the check is missing:

Comparator::diffForeignKey misses to compare the foreign table name, which can be added as this:

if ($key1->getForeignTableName() != $key2->getForeignTableName()) {
       return true;
}
Comment by Joshua Smith [ 17/Oct/12 ]

I've looked through the bugs in the DBAL project that reference the Comparator and I can't find one for this issue.

Has one been created for it that I have missed?

Also, I tried adding the suggested code into my project and schema-tool:update generated SQL to drop and recreate every foreign key relationship. I applied those changes and ran schema-tool:update again, expecting to get the normal "nothing to update" message. What I got was SQL to drop and recreate every foreign key relationship. Again.

Tracing the code revealed that (in one case) $key1->getForeignTableName() was returning 'user' and $key2->getForeignTableName() was returning 'User'. All of the foreign key comparisons followed the same pattern. I applied strtolower() to each of them before the comparison and now things seem to behave as I expect, but I don't know how portable my solution is.

if (strtolower($key1->getForeignTableName()) != strtolower($key2->getForeignTableName())) {
    return true;
}

I think applying strtolower() like this is OK since something similar is done when comparing local columns and foreign columns earlier in Comparator::diffForeignKey().

Comment by Benjamin Eberlei [ 01/Apr/13 ]

This was fixed in https://github.com/doctrine/dbal/commit/d7908fee and is part of Doctrine 2.3





[DBAL-478] [GH-295] Fix ModifyLimitQueryTest Created: 30/Mar/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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.



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

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





[DBAL-477] Just doublequote all schema names and field names in PostgreSQL sql command generation, and the same for MySQL Created: 28/Mar/13  Updated: 28/Mar/13

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

Type: Improvement Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, postgresql
Environment:

Any PostgreSQL environment



 Description   

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)






[DBAL-476] [GH-294] Allow removing column comment on some platforms Created: 28/Mar/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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.



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

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





[DBAL-475] [GH-293] Add SAP SQL Anywhere database vendor Created: 28/Mar/13  Updated: 14/Apr/13

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

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


 Description   

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






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

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

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql, schematool
Environment:

Windows & Linux



 Description   

Dear Symfony team,

the filterExpression on AbstractSchemaManager seems not to work for sequences.

This only happens under postgres.

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

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

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

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



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

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

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

Dear Benjamin,

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





[DBAL-473] [GH-292] Add length in the OCI8 bindParam Created: 26/Mar/13  Updated: 26/Mar/13  Resolved: 26/Mar/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 26/Mar/13 ]

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





[DBAL-472] Oracle schema modification - incorrect SQL to change the nullable status of column Created: 26/Mar/13  Updated: 04/Apr/13

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

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

Centos 6 PHP 5.3.3 Oracle 11g



 Description   

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



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

Works for me strangely.





[DBAL-471] when persisting objects to Doctrine2 and one of the tables are named the same as a MySQL reserved word Created: 24/Mar/13  Updated: 24/Mar/13  Resolved: 24/Mar/13

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

Type: Improvement Priority: Minor
Reporter: Per-Øivin Berg Andersen Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

MySQL on Ubuntu



 Description   

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.



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

Doctrine 2 ORM allows you to define "naming strategies" and/or to quote the table names with mysql-style ticks that get automatically quoted, like:

/** @ORM\Table(name="`foo`") */




[DBAL-470] [GH-291] Optimize abstract platform Created: 24/Mar/13  Updated: 24/Mar/13

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

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


 Description   

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.






[DBAL-469] [GH-290] Quote sequence name in PostgreSQL before grabbing information about it Created: 22/Mar/13  Updated: 04/May/13  Resolved: 04/May/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 22/Mar/13 ]

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

Comment by Benjamin Eberlei [ 04/May/13 ]

Closed by author





[DBAL-468] [GH-288] Fix fetchColumn not caching Created: 20/Mar/13  Updated: 20/Mar/13

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

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


 Description   

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.






[DBAL-467] DateTime handling in sqlsrv 2005 not quite right Created: 20/Mar/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

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

window, sql svr 2005



 Description   

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.



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

You can register your own type to handle this, or use the "VarDateTime" that is more flexible with this kind of date format.

Comment by Benjamin Eberlei [ 01/Apr/13 ]

I have clarified the VarDateTime approach in the SQL Server Platform Known Issues and Limitations documentation.





[DBAL-466] [GH-287] Fix platform create constraint foreign table name quotation Created: 19/Mar/13  Updated: 19/Mar/13  Resolved: 19/Mar/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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.



 Comments   
Comment by Benjamin Eberlei [ 19/Mar/13 ]

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





[DBAL-465] [GH-286] Fix data not being cached in ResultCache Created: 19/Mar/13  Updated: 20/Mar/13  Resolved: 20/Mar/13

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

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


 Description   

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.



 Comments   
Comment by Benjamin Eberlei [ 20/Mar/13 ]

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

Comment by Benjamin Eberlei [ 20/Mar/13 ]

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

Comment by Benjamin Eberlei [ 20/Mar/13 ]

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





[DBAL-464] MySQL fails when try to drop a primary index with Auto Increment Created: 14/Mar/13  Updated: 14/Mar/13

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

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

Linux (ubuntu), PHP 5.3.10, MySQL 5.5.29, Symfony2



 Description   

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.






[DBAL-463] [GH-285] Add IBM iSeries Driver Created: 12/Mar/13  Updated: 14/Mar/13

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

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


 Description   

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

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

Message:

Added driver pdo_ibmi to support to db2 iSeries using pdo_odbc






[DBAL-462] [GH-284] Correcting code example Created: 10/Mar/13  Updated: 10/Mar/13  Resolved: 10/Mar/13

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

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


 Description   

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()



 Comments   
Comment by Benjamin Eberlei [ 10/Mar/13 ]

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





[DBAL-461] Numeric() syntax in columns fails on SQL Server Created: 07/Mar/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

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

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


 Description   

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".



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

Fixed





[DBAL-460] [GH-283] Fix SchemaManagerFunctionalTestCase composite foreign keys test Created: 05/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

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

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


 Description   

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

Url: https://github.com/doctrine/dbal/pull/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.



 Comments   
Comment by Benjamin Eberlei [ 12/Mar/13 ]

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





[DBAL-459] [GH-282] Add column collation support for SQL Server Created: 05/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

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

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


 Description   

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

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

Message:

This PR contributes to PR #274 and adds the missing SQL Server driver support for column collations. It's fully functional tested on my own SQL Server database.



 Comments   
Comment by Benjamin Eberlei [ 12/Mar/13 ]

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





[DBAL-458] [GH-281] Upgrading doctrine/common 2.4 (via composer) Created: 04/Mar/13  Updated: 04/Mar/13  Resolved: 04/Mar/13

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

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


 Description   

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

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

Message:

This PR introduces changes necessary to make the DBAL recognize `"doctrine/common": "2.4"` as compatible as discussed in https://groups.google.com/d/topic/doctrine-dev/8WjzboENQgg/discussion

Ping @dbu



 Comments   
Comment by Benjamin Eberlei [ 04/Mar/13 ]

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





[DBAL-457] [GH-280] Use int values instead of strings for PostgreSQL booleans Created: 04/Mar/13  Updated: 04/Mar/13  Resolved: 04/Mar/13

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

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


 Description   

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

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

Message:

    1. The Problem:
      The current implementation for PostgreSQL uses strings 'true' and 'false' which are not working with PDO::ATTR_EMULATE_PREPARES.
    1. Solution:
      Use ints like in the default platform implementation.
    1. Comments
  • Tested only on my local php 5.4.9
  • Fixed NamedParametersTest to use int columns instead of strings (does not work with PDO::ATTR_EMULATE_PREPARES when compare string column IN array of ints)
  • Fixed DbalFunctionalTestCase sql parameters dumping (found while fixing NamedParametersTest)
  • Added support for driver options configuration via phpunit config globals


 Comments   
Comment by Benjamin Eberlei [ 04/Mar/13 ]

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

Comment by Marco Pivetta [ 04/Mar/13 ]

Solved at https://github.com/doctrine/dbal/commit/55128a6549b777ec91d7808989df236dbd508111





[DBAL-456] [GH-279] adds new output format Created: 03/Mar/13  Updated: 05/Mar/13  Resolved: 05/Mar/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

The output of the ::dump command is very unstable (depends on platform/PHP version/installed extensions).

This pull request adds a new format which is more suitable for machine consumption.



 Comments   
Comment by Benjamin Eberlei [ 04/Mar/13 ]

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





[DBAL-455] [GH-278] OraclePlatform sequence naming for primary keys Created: 02/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

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

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


 Description   

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

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

Message:

Change Oracle sequence generation to match what is being created by ORM and other platforms in the form of $table_$column_SQL instead of $table_SEQ

This is a solution for https://github.com/doctrine/migrations/issues/112



 Comments   
Comment by Benjamin Eberlei [ 12/Mar/13 ]

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





[DBAL-454] [GH-277] Remove duplicate SQL parts in query generation Created: 02/Mar/13  Updated: 03/Mar/13  Resolved: 03/Mar/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Presently, it's possible to do this using QueryBuilder:

```php
$qb->select('u.*')
->from('users', 'u')
->addOrderBy('u.name', 'ASC')
->addOrderBy('u.name', 'ASC'); // duplicate
```
Which produces:
```sql
SELECT u.* FROM users u ORDER BY u.name ASC, u.name ASC
```

This patch removes duplicates from the `SELECT`, `SET`, `ORDER BY` and `GROUP BY` parts during SQL generation (there's already logic that removes duplicate `FROM` parts).

I've added test cases for each affected keyword as well.



 Comments   
Comment by Benjamin Eberlei [ 03/Mar/13 ]

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





[DBAL-453] PostgreSqlSchemaManager::getSchemaSearchPaths does not work for secondary schemas Created: 24/Feb/13  Updated: 01/May/13  Resolved: 01/May/13

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

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

Postgresql 9.1 on Ubuntu 12.04



 Description   

PostgreSqlSchemaManager::getSchemaSearchPaths() uses "SHOW search_path" to get the current search path for the connection and explodes it using a comma delimiter. On my installation Postgresql 9.1 on Ubuntu 12.04 "SHOW search__path" returns the schemas in the search path separated by ", " (i.e. a comma followed by a space). This means that the array of schemas returned by getSchemaSearchPaths() will including a leading space on the schema names for the second and subsequent schemas in the search list.

This is a particular problem if you call PostgreSqlSchemaManager::getExistingSchemaSearchPaths() because that calls determineExistingSchemaSearchPaths() which filters the list from getSchemaSearchPaths() to make sure they are in the list of schemas in the database (as returned from getSchemaNames(). The second and subsequent schemas in the search path still have a leading space when they are compared to the array of schema names, and consequently they do not match and are not included in the array returned by getExistingSchemaSearchPaths().

I think that getSchemaSearchPaths should trim the leading space from the schemas.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed in 2.3.4





[DBAL-452] range is a reserved word in several platforms Created: 21/Feb/13  Updated: 15/Mar/13  Resolved: 14/Mar/13

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

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

Linux 64bit



 Description   

'range' is a reserved word for MySQL, Oracle, and on future reserved list for SQL Server as well so should really be added for escaping. Working on a new project using Doctrine accessing an external API which used it as a field and got an error when running orm:schema-tool:create on my entity with MySQL.



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

Added for MySQL and Oracle. Didn't find data on when its added to SQL Server.

Comment by Michael Cummings [ 15/Mar/13 ]

http://msdn.microsoft.com/en-us/library/ms189822.aspx under Future Keywords





[DBAL-451] [GH-276] DBAL-446 Created: 19/Feb/13  Updated: 06/Apr/13  Resolved: 06/Apr/13

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

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


 Description   

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

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

Message:

Fix for DBAL-446 with a proper test case and two general test cases.






[DBAL-450] [GH-275] accept array as parameter in getConcatExpression Created: 19/Feb/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

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

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


 Description   

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

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

Message:

The function `getConcatExpression` accepts strings, but as there can be any number of parameters passed to this and while calling from `ConcatFunction` sqlwalker has to walk all the parameters. So it would be better if `getConcatExpression` accepts array. Infact even better if it only accepts array. It would be much cleaner. Also I am opening a pull request in ORM for `ConcatFunction` as it only validates 2 primaryStrings. It should support more than two. SO for that to happen, `getConcatExpression` should accept array as parameter.






[DBAL-449] [GH-274] Support column charset/collation on capable platforms Created: 19/Feb/13  Updated: 19/Feb/13

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

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


 Description   

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

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

Message:

Basically the same feature wanted as in #245






[DBAL-448] [GH-273] Use BLOB for Object mapping type Created: 17/Feb/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

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

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


 Description   

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

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

Message:

http://php.net/manual/en/function.serialize.php
> Note that this is a binary string which may include null bytes, and needs to be stored and handled as such. For example, serialize() output should generally be stored in a BLOB field in a database, rather than a CHAR or TEXT field.






[DBAL-447] [GH-272] Refactor SQL Server keyword dictionaries and MsSQL leftovers Created: 13/Feb/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

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

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


 Description   

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

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

Message:

Each Microsoft SQL Server version has its own specific reserved keyword dictionary. Therefore each platform version should implement the correct dictionary. This PR adds dedicated dictionaries for Microsoft SQL Server 2000 (base), 2005, 2008 and 2012. Moreover all the "mssql" leftovers are refactored to fit the "sqlserver" term.






[DBAL-446] Type json_array can't be null Created: 13/Feb/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

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


 Description   

Column type json_array can be set to nullable, but if there's null in the database, it is returned as an empty array to PHP.

Null should be returned instead, as that's how the other types behave too.



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

This was fixed in 2.3.3





[DBAL-445] [GH-271] added the possibility to use column names as keys for the types in Connection::insert() Created: 12/Feb/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

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


 Description   

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

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

Message:

The Connection::insert() method takes an array of types as its third argument:

$conn->insert('foo', array('foo' => 'foo', 'date' => new \DateTime()), array(2 => 'datetime'));

But without looking at the implementation, I'm sure you would have written the following instead:

$conn->insert('foo', array('foo' => 'foo', 'date' => new \DateTime()), array('date' => 'datetime'));

But unfortunately, that's does not work. This commit add support for this, and of course, the old way still works.



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

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





[DBAL-444] OraclePlatform getSequenceNextValSQL not handling case/quoting properly on 11g Created: 10/Feb/13  Updated: 04/Apr/13

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

Type: Bug Priority: Major
Reporter: Max Milaney Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: oci8, oracle, sequence
Environment:

PHP version 5.4.11
Oracle 11g Instant Client version 11.2.0.3.0
Oracle Database 11g Enterprise Edition version 11.2.0.3.0 (x64)
OCI8 DBAL driver


Attachments: File example.php    

 Description   

I have an installer script that uses ORM SchemaTool to create the entities in the DB and then populates with basic data using basic EM->persist calls via ORM.

Sequence objects are created, and when using the 10g Instant Client everything worked correctly, however, upon upgrade to latest version of the Instant Client Oracle seems to be expecting consistent case for these schema objects. It appears as if they are being created with a quoted name as they are created in lowercase. OraclePlatform::getSequenceNextValSQL, however, generates "SELECT entity_id_seq.nextval FROM DUAL" and this fails with error "General error: 2289 OCIStmtExecute: ORA-02289: sequence does not exist".

Executing "SELECT "entity_id_seq".nextval FROM DUAL" directly on the DB returns the correct value.

I believe this may also impact the code in http://www.doctrine-project.org/jira/browse/DBAL-278



 Comments   
Comment by Max Milaney [ 10/Mar/13 ]

Hi there,
Wondering if there is any update on this? I'm having to use a workaround in my applications.
Cheers,
Max

Comment by Benjamin Eberlei [ 14/Mar/13 ]

Can you maybe show an entity definition with its sequence mapping?

Comment by Max Milaney [ 17/Mar/13 ]

Here you are mate. Please see attachment.

Comment by Benjamin Eberlei [ 04/Apr/13 ]

I cant seem to find the problem, in DBAL "lib/Doctrine/DBAL/Platforms/OraclePlatform.php" on line 171, the sequence statement is created with $sequence->getQuotedName($platform), but this only works if quoting is requrested for the sequence.

How do you actually create the sequence? Your entity doesnt have @GeneratedValue.

What does the create schema command say with "--dump-sql" flag? Is the SQL quoted?





[DBAL-443] [GH-270] Fix for DBAL-442 Created: 10/Feb/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

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


 Description   

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

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

Message:



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

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

Comment by Benjamin Eberlei [ 14/Apr/13 ]

Invalid branch





[DBAL-442] Break the query building with multiple from parts Created: 10/Feb/13  Updated: 22/Apr/13  Resolved: 22/Apr/13

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

Type: Bug Priority: Major
Reporter: Denis Vasilev Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: mysql


 Description   

For example:

$queryBuilder
    ->select('DISTINCT c.id')
    ->from('Campaigns', 'c')
    ->leftJoin('c', 'CampaignOperations', 'od', 'od.campaignId = c.id AND od.operation = :operation')
    ->from('BannerGroups', 'bg')
    ->innerJoin('bg', 'BannerGroupStrategies', 'bgs', 'bgs.groupId = bg.id AND bgs.advSystem = :system')
    ->where('bg.campaignId = c.id');

Builded the query:

SELECT DISTINCT c.id FROM Campaigns s 
  LEFT JOIN CampaignOperations od ON (od.campaignId = c.id AND od.operation = :operation)
  INNER JOIN BannerGroupStrategies bgs ON (bgs.groupId = bg.id AND bgs.advSystem = :system), 
  BannerGroups bg
  WHERE (bg.campaignId = c.id)

If this query execute on mysql, we get error:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'bg.id' in 'on clause'

Expected result:

SELECT DISTINCT c.id FROM Campaigns s 
  LEFT JOIN CampaignOperations od ON (od.campaignId = c.id AND od.operation = :operation),
  BannerGroups bg
  INNER JOIN BannerGroupStrategies bgs ON (bgs.groupId = bg.id AND bgs.advSystem = :system)
  WHERE (bg.campaignId = c.id)

Regression after patch https://github.com/doctrine/dbal/pull/175



 Comments   
Comment by Denis Vasilev [ 10/Feb/13 ]

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

Comment by Fabio B. Silva [ 22/Apr/13 ]

Fixed by : https://github.com/doctrine/dbal/commit/99574240f332a814ec193b6e7a88abb6a457f061





[DBAL-441] [GH-269] Fix SQLServerPlatform regular expression SQL Created: 03/Feb/13  Updated: 03/Feb/13  Resolved: 03/Feb/13

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

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


 Description   

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

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

Message:

SQL Server has no native support for regular expressions. Furthermore there is no "RLIKE" expression in T-SQL. This PR fixes this.



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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





[DBAL-440] [GH-268] Remove deprecated getShowDatabasesSQL() from Platforms Created: 03/Feb/13  Updated: 10/Feb/13  Resolved: 10/Feb/13

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

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


 Description   

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

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

Message:

As stated in PR #265 the getShowDatabasesSQL() method is deprecated in the platforms. This PR removes them entirely now.



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Alexander [ 10/Feb/13 ]

Was merged in https://github.com/doctrine/dbal/commit/fc77f6de46d936552b445920a80b12af2c019cd4





[DBAL-439] [GH-267] Add SQLServerPlatform supports schemas Created: 03/Feb/13  Updated: 05/Feb/13  Resolved: 05/Feb/13

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

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


 Description   

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

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

Message:

SQL Server supports schemas. This PR modifies SQLServerPlatform to return true when asked for schema support.



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Fabio B. Silva [ 05/Feb/13 ]

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





[DBAL-438] [GH-266] Removed outdated methods in DatabasePlatformMock. Created: 03/Feb/13  Updated: 05/Feb/13  Resolved: 05/Feb/13

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

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


 Description   

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

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

Message:

Same as https://github.com/doctrine/doctrine2/pull/567



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Fabio B. Silva [ 05/Feb/13 ]

Merged : https://github.com/doctrine/dbal/commit/2a58ac0e15315b785f3ee5edb822dc5e45d154d7





[DBAL-437] [GH-265] fix getShowDatabasesSQL() in SQLServerPlatform Created: 01/Feb/13  Updated: 10/Feb/13  Resolved: 10/Feb/13

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

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


 Description   

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

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

Message:

The getShowDatabasesSQL() in SQLServerPlatform returns invalid SQL. Maybe copy/paste error from MySqlPlatform? This PR fixes this to return the correct statement.



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Alexander [ 10/Feb/13 ]

PR was invalid.





[DBAL-436] Logger should specify connection used in a master/slave situation Created: 31/Jan/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

Type: Bug Priority: Major
Reporter: Jarrod Nettles Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

Suppose there is a master connection with four slaves specified. Connections are being handled by the Doctrine\DBAL\Connections\MasterSlaveConnection class. Under the current implementation, all queries are logged under the "master" connection, even queries that are routed to the slaves by the Doctrine\DBAL\Connections\MasterSlaveConnection class.

Since slave connections are separate, distinct connections, queries should be logged appropriately under their respective connections.



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

Two reasons why this is not feasible:

1. We actually don't ship loggers on our own, so if you want you can implement this yourself. We wouldn't have a way to "add" this, we only provide the interface.

2. However the logger does not have access to the connection to find out which slave or master its currently using, you can create a logger that has a "setConnection($conn)" method and call this during bootstrapping the logger+connection.





[DBAL-435] [GH-264] Allow passing empty arrays as parameters Created: 31/Jan/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

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


 Description   

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

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

Message:

Right now something like

```php
$entityManager
->createQuery("SELECT e FROM Entity e WHERE e IN (:entities)")
->execute(array('entities' => array()));
```

produces a `Warning: array_fill(): Number of elements must be positive`






[DBAL-434] Incorrect type mapping on Oracle Platform Created: 30/Jan/13  Updated: 17/Feb/13  Resolved: 30/Jan/13

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

Type: Bug Priority: Critical
Reporter: Damián Nohales Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

Oracle 10g on Windows, using Doctrine 2 with Symfony2



 Description   

Hello,

I'm noticed a strange behaviour when I executed a migration for my Oracle database. Doctrine detects changes on all date columns, generating queries like:

ALTER TABLE the_table MODIFY (the_date DATE DEFAULT NULL);

even if the entity property was not modified. Check in out the Doctrine 2 source code I've detected that Doctrine map the DATE Oracle columns as datetime type, but entity date property are mapped as date (as it should be), so Doctrine believes that entity property and column type are different and generate the alter query.

I found the problem on the method Doctrine\DBAL\Platforms\OraclePlatform::initializeDoctrineTypeMappings, when it say 'date' => 'datetime' should say 'date' => 'date', that fix the migration problem and does not break my application.

Was a typo?

Thanks!



 Comments   
Comment by Benjamin Eberlei [ 30/Jan/13 ]

The problem is that Oracle has a "DATE" type, which is actually a DATETIME. That is why we map it to Doctrine's Datetime type.

As a workaround, you can set this information yourself using:

$conn->getDatabasePlatform()->registerDoctrineTypeMapping('date', 'date');

Be aware this is a global change for all columns. If you map DateTimes to a TIMESTAMP field you are good to go though.

Comment by John Kary [ 17/Feb/13 ]

I ran into this same issue with the default OraclePlatform configuration. I was trying to run doctrine:schema:update --force from the Symfony2 Console on my Oracle database, and ALTER statements were generated for some DATE columns that were fully up to date when looking at the actual table.

But the major issue I ran into was these unnecessary ALTER statements were for DATE columns with NOT NULL constraints, resulting in a query like ALTER TABLE your_table MODIFY (created_at_date DATE NOT NULL); Yet when running this query, Oracle throws an error: ORA-01442: column to be modified to NOT NULL is already NOT NULL. So I could no longer use doctrine:schema:update to update my schema during development against Oracle.

While technically correct, Oracle DATE types actually store time data in addition to date data, I don't agree that this should be considered Doctrine's default behavior.

I believe Oracle DATE columns should be date-only (e.g. Day, Month, Year) and time data should be disregarded. All other drivers except SQLServer map "date" fields to Doctrine's "date" type. I would rather see someone wanting to store time data with their DATE field need to make the suggested change, instead of the other way around:

$conn->getDatabasePlatform()->registerDoctrineTypeMapping('date', 'datetime');

Oracle 11g Release 1 DATE type docs: http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#i1847)

Comment by Benjamin Eberlei [ 17/Feb/13 ]

Well the other thing is, that we cannot change this for BC reasons.

We could introduce a new platform that solves this issue though.





[DBAL-433] [GH-263] Fix wrong class names in SQLAzureFederationsSynchronizer Created: 29/Jan/13  Updated: 30/Jan/13  Resolved: 30/Jan/13

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

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


 Description   

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

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

Message:

There is a wrong import in this class:

use Doctrine\DBAL\Sharding\SingleDatabaseSynchronizer;

Should be:

use Doctrine\DBAL\Schema\Synchronizer\SingleDatabaseSynchronizer;

The following import is also missing:

use Doctrine\DBAL\Schema\Synchronizer\SchemaSynchronizer;

This PR fixes them.



 Comments   
Comment by Benjamin Eberlei [ 30/Jan/13 ]

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





[DBAL-432] [GH-262] Add Symfony Console dependency to composer.json Created: 29/Jan/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

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


 Description   

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

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

Message:

The DBAL component offers a command-line tool based on Symfony Console, but this one is not present as a dependency in `composer.json`.

This PR adds the dependency.



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

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





[DBAL-431] [GH-261] Fix OFFSET without LIMIT cause MySQL syntax error. Created: 29/Jan/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

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


 Description   

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

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

Message:

MySQL OFFSET require LIMIT.
So fixed it to use the biggest limit possible as it recommended in http://dev.mysql.com/doc/refman/5.0/en/select.html#id4651990



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

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





[DBAL-430] [GH-260] Add SQL Server 2012 platform Created: 29/Jan/13  Updated: 04/Feb/13  Resolved: 04/Feb/13

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

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


 Description   

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

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

Message:

This adds the platform for SQL Server 2012 introducing sequences. I don't exactly know if sequences should be preferred for ID generation or not so I left identity columns preferred for ID generation. Also added new keywords to MsSqlKeywords since SQL Server 2008.



 Comments   
Comment by Benjamin Eberlei [ 04/Feb/13 ]

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





[DBAL-429] [GH-259] fix named_token Created: 28/Jan/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

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


 Description   

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

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

Message:

Regex Token Pattern for NAMED_TOKEN does not support sql cast operator ::

For example a query like this:
Select mydate::date from mytable;

will return a place holder ':date' instead of ignoring this.

fixed by adjusting the regex to ignore the operator.



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

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





[DBAL-428] [GH-258] Guid type requires SQL typehint comment Created: 26/Jan/13  Updated: 30/Jan/13  Resolved: 30/Jan/13

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

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


 Description   

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

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

Message:

Since guid extends the string type, it needs to be type hinted.



 Comments   
Comment by Benjamin Eberlei [ 30/Jan/13 ]

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





[DBAL-427] [GH-257] fix SQLServerPlatform locking hints Created: 25/Jan/13  Updated: 03/Feb/13  Resolved: 03/Feb/13

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

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


 Description   

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

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

Message:

This should completely implement the locking hints of the SQLServerPlatform according to http://msdn.microsoft.com/en-us/library/aa213026%28v=sql.80%29.aspx.



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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





[DBAL-426] [GH-256] Create queryBuilder from parts. Created: 25/Jan/13  Updated: 26/Jan/13  Resolved: 26/Jan/13

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

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


 Description   

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

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

Message:

Add a feature that can create a queryBuilder from queryBuilder parts.

This can be used when a query is build and needs to be stored somehow and restore it later.



 Comments   
Comment by Benjamin Eberlei [ 25/Jan/13 ]

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





[DBAL-425] [GH-255] fix typo in AbstractPlatform phpDocs Created: 25/Jan/13  Updated: 26/Jan/13  Resolved: 26/Jan/13

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

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


 Description   

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

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

Message:

Fixes typo in AbstractPlatform phpDocs. "ASNI" -> "ANSI"



 Comments   
Comment by Benjamin Eberlei [ 25/Jan/13 ]

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





[DBAL-424] [GH-254] fix SQLServerPlatform GUID expression Created: 25/Jan/13  Updated: 25/Jan/13  Resolved: 25/Jan/13

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

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


 Description   

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

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

Message:

The GUID expression UUID() does not exist in SQLServer. Instead NEWID() is used. This PR fixes this.



 Comments   
Comment by Benjamin Eberlei [ 25/Jan/13 ]

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





[DBAL-423] Type GUID = VARCHAR(255) on platforms that don't have a native GUID support Created: 25/Jan/13  Updated: 25/Jan/13

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

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


 Description   

I'm using MySQL with entities that have GUID ids. Therefore I'm using @ORM\Column(type="guid") for the ORM mapping. As MySQL does not have a native GUID data type, it gets mapped to type="string" with a default length of 255 -> VARCHAR(255). I don't really understand why we don't limit the length to 36, which is the fixed length for GUIDs. You could even think about using CHAR(36) for MySQL.

-> see Doctrine\DBAL\Platforms\AbstractPlatform -> getGuidTypeDeclarationSQL()






[DBAL-422] Wrong VARCHAR default length in SQLServerPlatform Created: 24/Jan/13  Updated: 24/Jan/13

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

Type: Bug Priority: Minor
Reporter: Steve Müller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: platform, sqlserver, sqlsrv, varchar


 Description   

In SQLServerPlatform the default length for a VARCHAR declaration is set to "255". But according to the SQLServer documentation from Microsoft the default length is "1", if omitted in the declaration.
See remarks: http://msdn.microsoft.com/en-us/library/ms186939.aspx
Also the default length is hardcoded in the "getVarcharTypeDeclarationSQLSnippet" method which in my opinion should be evaluated through "getVarcharDefaultLength".

I don't exactly know if the current implementation is intended, otherwise it should be fixed. I would then create an PR if desired.






[DBAL-421] [GH-253] Added GUID expression to SQLite platform Created: 23/Jan/13  Updated: 25/Jan/13  Resolved: 25/Jan/13

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

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


 Description   

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

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

Message:

This will add an implementation of getGuidExpression to the SqlitePlatform. It is based on [UUID version 4](http://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_.28random.29).

Don't know if this is appropriate, but I'm open to suggestions.



 Comments   
Comment by Benjamin Eberlei [ 25/Jan/13 ]

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

Comment by Marco Pivetta [ 25/Jan/13 ]

merged





[DBAL-420] Schema Drop SQL incorrect on PostgreSQL with entities with GeneratedValue(strategy="IDENTITY") Created: 23/Jan/13  Updated: 14/Apr/13  Resolved: 14/Apr/13

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

Type: Bug Priority: Major
Reporter: Adam Ashley Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: postgresql, schematool
Environment:

Symfony 2.1, PHP5.4, PostgreSQL 9.1 on Ubuntu 12.04



 Description   

This problem is probably related to #DBAL-54. However that was closed by the raiser as he changed his Entity model and it went away.

When schema drop is run the following error occurs:
Doctrine\DBAL\DBALException: An exception occurred while executing 'DROP SEQUENCE radacct_radacctid_seq':

SQLSTATE[2BP01]: Dependent objects still exist: 7 ERROR: cannot drop sequence radacct_radacctid_seq because other objects depend on it
DETAIL: default for table radacct column radacctid depends on sequence radacct_radacctid_seq
HINT: Use DROP ... CASCADE to drop the dependent objects too.

The source of this problem is the difference between strategy="IDENTITY" and strategy="SEQUENCE"

With SEQUENCE doctrine creates the table schema with field type BIGINT and no specified. It then creates a seperate sequence and as far as I can tell takes care of getting and inserting the next id number itself.

With IDENTITY doctrine creates the table schema with field type BIGSERIAL and no specified default. Now postgres automatically creates a sequence and creates the column with type BIGINT and sets the DEFAULT to the pgpsql statement required to get the nextval from the sequence.

At this point the two differently configured tables will work successfully and identically, except SEQUENCE tables will only get a correct new ID when run through the doctrine code while IDENTITY tables will get the correct new ID whenever an insert is done to the table.

Because in the case of an IDENTITY field postgresql creates the field with a default value refering to the sequence the sequence can not be deleted before the table reference is removed.

For my case I need the IDENTITY fields to work as we have a RADIUS server that needs to insert into one table which is managed and mapped to an entity in Doctrine.

Swapping the order of DROP TABLE and DROP SEQUENCE commands in Doctrine/DBAL/Schema/Visitor/DropSchemaSqlCollector.php in getQueries() line 159. Does not work as a quick fix. The following error occurs as the sequence is quite correctly be dropped along with the table.

Doctrine\DBAL\DBALException: An exception occurred while executing 'DROP SEQUENCE radacct_radacctid_seq':

SQLSTATE[42P01]: Undefined table: 7 ERROR: sequence "radacct_radacctid_seq" does not exist



 Comments   
Comment by Adam Ashley [ 24/Jan/13 ]

This issue also appears to affect Doctrine_Migrations. Generated migrations try to drop and recreate automatically generated sequences associated with SERIAL fields making a mess of the database.

Comment by Benjamin Eberlei [ 22/Mar/13 ]

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

Comment by Adrien Crivelli [ 12/Apr/13 ]

@Adam Ashley, could you test whether https://github.com/doctrine/dbal/pull/289 solve your issue ?

Comment by Doctrine Bot [ 14/Apr/13 ]

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





[DBAL-419] [GH-252] Sqlserver limit Created: 22/Jan/13  Updated: 30/Jan/13  Resolved: 30/Jan/13

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

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


 Description   

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

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

Message:

Unfortunately fix from my last commit it not enough to handle more complicated queries.
This change should fix points 2 and 3 [from this list](http://www.doctrine-project.org/jira/browse/DDC-1785) but it also removes adding TOP statement if ``$offset`` is not set.
I know it looks realy messy but I can't figure out any other solution to handel queries with subqueries and ordering (such thing is generated after using Doctrine Paginator and ordering).



 Comments   
Comment by Benjamin Eberlei [ 30/Jan/13 ]

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





[DBAL-418] [GH-251] Escape identifier names in MySQL ALTER queries Created: 21/Jan/13  Updated: 01/Apr/13  Resolved: 01/Apr/13

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

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


 Description   

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

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

Message:

The generated MySQL queries did not properly escape the identifier, thus
making it impossible to use SQL keywords as field/index/table name.

Although this is indeed a quite unwise design choice, this is required
for many legacy applications.

The submitted modifications do cover MySQL only, because it is the one that I need to use. However, I think that all the platforms are flawed with this issue and that a general re-work should be done here.



 Comments   
Comment by Benjamin Eberlei [ 21/Jan/13 ]

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





[DBAL-417] [GH-250] Lightweight export as of doctrine/doctrine2#543 Created: 19/Jan/13  Updated: 19/Jan/13  Resolved: 19/Jan/13

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

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


 Description   

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

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

Message:

see doctrine/doctrine2#543



 Comments   
Comment by Benjamin Eberlei [ 19/Jan/13 ]

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





[DBAL-416] [GH-249] Fixed doModifyLimitQuery for SQLServerPlatform Created: 18/Jan/13  Updated: 20/Jan/13  Resolved: 20/Jan/13

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

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


 Description   

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

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

Message:

It seems that there is a problem in SQLServerPlatform ``doModifyLimitQuery`` method.
I can't use Doctrine ORM Paginator because of wrong position of ``DISTINCT`` statement in final limit subquery, here is the exception message I'm getting.
``SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'DISTINCT'.``

My proposition is to change ``doModifyLimitQuery`` result from:

``SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY username DESC) AS doctrine_rownum, * FROM user) ...``

into:

``SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY username DESC) AS doctrine_rownum FROM user) ...``



 Comments   
Comment by Benjamin Eberlei [ 20/Jan/13 ]

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





[DBAL-415] [GH-248] Enable multiple postgresql datetime formats Created: 14/Jan/13  Updated: 14/Jan/13

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

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


 Description   

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

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

Message:

Postgre use ISO 8601 date formats so some times can be Y-m-d H:i:s or sometime Y-m-d H:i:s.u






[DBAL-414] zaza Created: 09/Jan/13  Updated: 09/Jan/13  Resolved: 09/Jan/13

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

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

aaan



 Description   

yu



 Comments   
Comment by batbileg [ 09/Jan/13 ]

yu wm





[DBAL-413] [GH-247] Obtain all informations about a column via Column::toArray() Created: 08/Jan/13  Updated: 08/Jan/13  Resolved: 08/Jan/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed 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/247

Message:



 Comments   
Comment by Benjamin Eberlei [ 08/Jan/13 ]

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





[DBAL-412] PostgreSqlSchemaManager::listTableColumns() fails if there are columns defined by domains in multiple schemas Created: 08/Jan/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms, Schema Managers
Affects Version/s: 2.3.1
Fix Version/s: 2.3.4
Security Level: All

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

Postgresql 9.1



 Description   

We use Postgresql Domains to ensure consistent column definitions across multiple tables. We also have multiple schemas in a database. Therefore we can have two domains defined in the same database with the same name, but in different schemas.

In this situation, PostgreSqlSchemaManager::listTableColumns() fails when called for a table with a column defined by one of those domains. This means that PostgreSqlSchemaManager::createSchema() also fails for a schema containing such a table.

```
SQLSTATE[21000]: Cardinality violation: 7 ERROR: more than one row returned by a subquery used as an expression
```

This happens because of an error in the query definition in PostgreSqlPlatform::getListTableColumnsSQL(). The domain_complete_type column in the query is defined by matching the name only, without reference to the schema:

(SELECT format_type(t2.typbasetype, t2.typtypmod) FROM   
  pg_catalog.pg_type t2                                                        
                       WHERE t2.typtype = 'd' AND t2.typname = format_type(a.atttypid, a.atttypmod)) AS domain_complete_type,                             

The error can be corrected by making sure that the correct domain is matched by using the OID instead of the name to match:

(SELECT format_type(t2.typbasetype, t2.typtypmod) FROM   
  pg_catalog.pg_type t2                                                        
                       WHERE t2.typtype = 'd' AND t2.oid = a.atttypid) AS domain_complete_type

I can create a GitHub PR if it helps.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed





[DBAL-411] Schema updater breaks when using backticks in tablenames. Created: 08/Jan/13  Updated: 08/Jan/13

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

Type: Bug Priority: Minor
Reporter: Endaco Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Debian Linux 6.0, PHP 5.3.3, MySQL 5.1.63



 Description   

When using backticks around table-names (for example "`Order`"), the Doctrine schema update tool wants to recreate all foreign keys on every run.

This error was introduced in commit cb3ec49cb4401bd1c8be6ba9671f651802586eaf






[DBAL-410] [GH-246] Fixed sql for creating table with fulltext index Created: 08/Jan/13  Updated: 08/Jan/13  Resolved: 08/Jan/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed 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/246

Message:



 Comments   
Comment by Benjamin Eberlei [ 08/Jan/13 ]

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





[DBAL-409] [GH-245] Added support for column collation Created: 08/Jan/13  Updated: 04/May/13

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

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


 Description   

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

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

Message:






[DBAL-408] [GH-244] Enable Postgresql plateform to map inet column type Created: 08/Jan/13  Updated: 08/Jan/13  Resolved: 08/Jan/13

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

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


 Description   

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

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

Message:

http://www.postgresql.org/docs/8.2/static/functions-net.html



 Comments   
Comment by Benjamin Eberlei [ 08/Jan/13 ]

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





[DBAL-407] Refactor exceptions Created: 07/Jan/13  Updated: 06/May/13

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

Type: Improvement Priority: Major
Reporter: Bart van den Burg Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

It's currently rather hard to figure out what went wrong when for example a DBALException was thrown. You have to actually match the message in it, or read the status code of the ->getPrevious() exception, which can be different for all drivers (as https://github.com/jackalope/jackalope-doctrine-dbal/issues/80 shows).

I'd suggest creating new exception classes for all situations and throwing them instead. If they extend the DBAL Exception and pass the message to it as it is right now, there will be no BC break.

If this were to be done, on which branch should this be applied?



 Comments   
Comment by Christophe Coevoet [ 07/Jan/13 ]

This should be done in the master branch.

Another solution, avoiding to create many classes, would be to use the exception code, which is always kept as 0 currently (the default value of the Exception class). You could have a code for each case (with constants in the DBALException class) and then checking $e->getCode() to identify what went wrong.

Comment by Bart van den Burg [ 07/Jan/13 ]

I'd prefer actual named exceptions. It makes catching them simpler. However, adding some code defined in DBAL would be an acceptable alternative.

try {
    /* ... /*
} catch (NoSuchTableException $e) {
    // do something
} catch (DuplicateKeyException $e) {
    // do something else
}

v.s.

try {
    /* ... /*
} catch (DBALException $e) {
    if ($e->getCode() == DBALException::NO_SUCH_TABLE) {
        // do something
    } elseif ($e->getCode() == DBALException::DUPLICATE_KEY) {
        // do something else
    } else {
        throw $e;
    }
}
Comment by Christopher Davis [ 06/May/13 ]

I would also prefer named exceptions. You're going to have a lot of problems providing the "code" value in DBALException in any case: SQLSTATE codes are alphanumeric, and will cause warnings/errors when creating new exception.

Besides we can get the SQL state code now:

    try {
        // ...
    } catch (\Doctrine\DBAL\DBALException $e) {
        $code = $e->getPrevious()->getCode();
        // do stuff with $code
    }

The problem is that there are a lot of error codes defined in the ANSI SQL standard: http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html

Maybe throwing an specific exception for each "class" of SQLSTATE codes? So if the error code from a PDO exception starts with 23, DBAL would throw `\Doctrine\DBAL\Exception\IntegrityConstraintViolationException`.

This also seems like the logic to handle throwing exceptions should be contained in the platforms as some implementations may differ. You could have a method in `AbstractPlatform` that takes care of the ANSI SQLSTATE error code classes and leave it up subclasses to deal with platform specific cases. Whenever `Connection` catches a `PDOException`, dispatch it to the platform to deal with.

Example: https://gist.github.com/chrisguitarguy/e021918900e93dca304d

Thoughts?

Comment by Matthieu Napoli [ 06/May/13 ]

I have implemented a thing of that kind in a personal project (on top of Doctrine). It is really useful to be able to catch a ForeignKeyViolationException, and get with entity/field caused the problem (for that my EntityManager wrapper parse the exception message).

However, note that exception codes differ from DB engines. In my case, I did it quick and used MySQL error codes, but managing different RDBMS implies more work.





[DBAL-406] PostgreSqlSchemaManager::tablesExist() misses schema-qualified table names if they exist in the first schema on the search path Created: 07/Jan/13  Updated: 07/Jan/13

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

Type: Bug Priority: Minor
Reporter: Roger Hunwicks Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql
Environment:

Postgresql 9.1



 Description   

Please see https://github.com/doctrine/migrations/issues/99 for additional background.

To reproduce:

CREATE SCHEMA test_schema;
CREATE TABLE test_schema.test_table (test_column TEXT);

Then in Doctrine:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
$connection->executeUpdate('SET search_path=test_schema;');
$result = $connection->getSchemaManager()->tablesExist(array('test_schema.test_table'));

$result is false when it should be true.

The error occurs because PostgreSqlSchemaManager returns the bare table name from getPortableTablesList() if the schema is the first one in the search path.

The full explanation is...

AbstractSchemaManager::tablesExist() calls $this->getPortableTablesList() before checking if the tables exist.

PostgreSqlSchemaManager overrides this in _getPortableTableDefinition() by comparing the schema for the table with the search path for the connection. If the table schema is the first one in the search path, then it returns the bare table name, if it isn't then it returns the schema-qualified table name (i.e. schema.table).

tablesExist() does an array_intersect to check that all the tables in the search array exist in the database.

If one of the tables in the search array was schema-qualified but also in the first schema on the search path, then you end up checking:

array_intersect(array('test_schema.test_table'), array('test_table'))

which fails.

One way to fix it would be to override tablesExist() in PostgreSqlSchemaManager so that it passes the search array through getPortableTableDefinition() before doing the array_intersect:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
    /**
     * Return true if all the given tables exist.
     *
     * @param array $tableNames
     * @return bool
     */
    public function tablesExist($tableNames)
    {
        foreach ($tableNames as $key => $tableName) {
            if (strpos($tableName, '.') !== false) {
                $tableName = explode('.', $tableName, 2);
                $tableNames[$key] = $this->_getPortableTableDefinition(array('schema_name'=>$tableName[0], 'table_name'=>$tableName[1]));
            }
        }
        return parent::tablesExist($tableNames);
    }

I'm happy to provide a PR on GitHub if you want.






[DBAL-405] [GH-241] Added support of key length for text indexes Created: 29/Dec/12  Updated: 30/Dec/12  Resolved: 30/Dec/12

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

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


 Description   

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

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

Message:






[DBAL-404] Support of index length for text fields Created: 29/Dec/12  Updated: 29/Dec/12

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

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


 Description   

For table with text field description with index on it generated query is:

CREATE TABLE t (id INT UNSIGNED AUTO_INCREMENT NOT NULL, description LONGTEXT DEFAULT NULL, number INT DEFAULT NULL, INDEX index2 (description), INDEX index3 (description, number), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB

This query lead to error, because for index on text field absented key length.






[DBAL-403] [GH-240] Fix for DBAL-209 Created: 29/Dec/12  Updated: 06/Jan/13  Resolved: 06/Jan/13

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

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


 Description   

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

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

Message:

Fix for DBAL-209



 Comments   
Comment by Benjamin Eberlei [ 06/Jan/13 ]

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





[DBAL-402] Fatal error: Uncaught exception Created: 29/Dec/12  Updated: 08/Apr/13

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

Type: Bug Priority: Blocker
Reporter: Ruslan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, oracle


 Description   
Fatal error: Uncaught exception 'Doctrine\DBAL\Driver\OCI8\OCI8Exception' with message 'ORA-00904: "T0"."ID": invalid identifier' in /var/www/doctrine/doctrine/lib/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Exception.php on line 28 Doctrine\DBAL\Driver\OCI8\OCI8Exception: ORA-00904: "T0"."ID": invalid identifier in /var/www/doctrine/doctrine/lib/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Exception.php on line 28

Call Stack: 0.0002 665368
1. {main}() /var/www/doctrine/doctrine/tools/sandbox/index.php:0 0.3389 6023864
2. Doctrine\ORM\EntityManager->find() /var/www/doctrine/doctrine/tools/sandbox/index.php:71 0.3514 8264024
3. Doctrine\ORM\Persisters\BasicEntityPersister->load() /var/www/doctrine/doctrine/lib/Doctrine/ORM/EntityManager.php:444 0.3521 8413576 
4. Doctrine\DBAL\Connection->executeQuery() /var/www/doctrine/doctrine/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:725 0.3532 8625920
5. Doctrine\DBAL\Driver\OCI8\OCI8Statement->execute() /var/www/doctrine/doctrine/lib/vendor/doctrine-dbal/lib/Doctrine/DBAL/Connection.php:635 Variables in local scope (#5): $hasZeroIndex = *uninitialized* $key = *uninitialized* $params = NULL $ret = FALSE $val = *uninitialized* 


 Comments   
Comment by Benjamin Eberlei [ 06/Jan/13 ]

Format code sample

Comment by Benjamin Eberlei [ 04/Apr/13 ]

What is wrong here? The error alone is not very helpful





[DBAL-401] Log connection info with SQL logger Created: 28/Dec/12  Updated: 28/Dec/12  Resolved: 28/Dec/12

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

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


 Description   

while using MasterSlave connection, it would be nice to see the connection being used ( master or which slave), this will help debug the app, if lots read queries are going to Master



 Comments   
Comment by Benjamin Eberlei [ 28/Dec/12 ]

It is possible already, when you have a logger that has access to the connection again. MasterSlaveConnection#isConnectedToMaster() can be used to check. Since we don't provide any useful loggers for production anyways this is up to your own logger.

Comment by Ananda Agrawal [ 28/Dec/12 ]

thanks Eberlei, when using SQLLogger I donot get much information other than the query and params etc, I am using DebugStack or willing to extend it but Connection objects looks like they donot send much info, is there a way this could be achieved





[DBAL-400] can't add primary key to mysql table after the table is created Created: 20/Dec/12  Updated: 20/Dec/12

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

Type: Bug Priority: Minor
Reporter: John Robeson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

A table in this application had no primary keys. I created an entity
so i could attempt to use the doctrine:schema:update command to fix it up.

When i attempted to add this:

  • @ORM\Id
  • @ORM\GeneratedValue(strategy="NONE")

to this:

  • @ORM\Column(name="session_id", type="string", length=128,
    nullable=false)

it generates SQL like this:

ALTER TABLE whos_online DROP INDEX idx_session_id_zen, ADD UNIQUE INDEX primary (session_id);
ALTER TABLE whos_online CHANGE ip_address ip_address VARCHAR(45) NOT NULL, CHANGE host_address host_address VARCHAR(512) NOT NULL;

and says this:

An exception occurred while executing 'ALTER TABLE whos_online DROP INDEX idx_session_id_zen, ADD UNIQUE INDEX primary (session_id );
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to
your MySQL server version for the right syntax to use near 'primary (session_id)' at line 1






[DBAL-399] [GH-237] Do not treat assignment operator as a parameter DBAL-398 Created: 18/Dec/12  Updated: 22/Dec/12  Resolved: 22/Dec/12

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

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


 Description   

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

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

Message:

A native (mysql) query should be able to use the assignment operator := but currently the SQLParserUtils method treats that as a missing parameter.

The patch solves the issue, but it looks like a higher-level fix might be desired that also handles the regular expression better.



 Comments   
Comment by David Ward [ 18/Dec/12 ]

Noting that this auto-generated issue duplicates DBAL-398

Comment by Benjamin Eberlei [ 22/Dec/12 ]

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





[DBAL-398] Native query does not allow mysql assignment operator := Created: 18/Dec/12  Updated: 03/Jan/13  Resolved: 22/Dec/12

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

Type: Bug Priority: Major
Reporter: David Ward Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: mysql
Environment:

Using Doctrine within Symfony 2.1.x


Attachments: Text File FixNativeAssignmentOperator.patch    

 Description   

When trying to use the mysql assignment operator in a native query one gets an exception as SqlParserUtils does not qualify the character after the : as being part of a valid parameter value.

Undefined index: in vendor/doctrine/dbal/lib/Doctrine/DBAL/SQLParserUtils.php line 156 (uncaught exception)

A simple example is
$rsm = new ResultSetMapping();
$rsm->addScalarResult('rank', 'rank');
$qry = $em->createNativeQuery("
SELECT (@rank := 1) AS rank
");
$result = $qry->getResult(Query::HYDRATE_ARRAY);

Or a more complicated example is (similar to actual use):

$rsm = new ResultSetMapping();
$rsm->addScalarResult('rank', 'rank');
$qry = $em->createNativeQuery("
SELECT rank FROM
(SELECT (@rank := @rank +1) AS rank FROM (SELECT @rank :=0) rnk2) rnk1
");
$result = $qry->getResult(Query::HYDRATE_ARRAY);

I have attached quick-fix patch, but it looks like the getPlaceholderPositions method is wanting something better overall (due to the TODO comment in it).



 Comments   
Comment by David Ward [ 18/Dec/12 ]

A pull request has been added at https://github.com/doctrine/dbal/pull/237 which also has tests added.

Comment by Bryson Armstrong [ 03/Jan/13 ]

I ran into this error and the fix caused other queries to have errors.

I fixed it by changing line 57 in vendor/doctrine/dbal/lib/Doctrine/DBAL/SQLParserUtils.php:

 
if ($statement[$i] == $match && !$inLiteral && (!$isPositional && $statement[$i+1] != '=')) {

to:

if ($statement[$i] == $match && !$inLiteral && ($isPositional || $statement[$i+1] != '=')) {




[DBAL-397] PostgreSQL - getDateTimeTzFormatString() Created: 12/Dec/12  Updated: 17/Dec/12  Resolved: 16/Dec/12

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

Type: Bug Priority: Major
Reporter: Phill Pafford Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: datetime, dql, format, postgresql
Environment:

PostgreSQL Database



 Description   

In:

  • vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php

The function:

getDateTimeTzFormatString()

only returns one datetime format:


    /**
     * {@inheritDoc}
     */
    public function getDateTimeTzFormatString()
    {
        //return 'Y-m-d H:i:sO'; // original format
        return 'Y-m-d H:i:s.uO'; // format also needed
    }


Here is the error I get using the original format:

Could not convert database value "2012-12-07 16:01:52.580789-05" to Doctrine Type datetimetz. Expected format: Y-m-d H:i:s.O

If I use this format: 'Y-m-d H:i:s.uO' it works.



 Comments   
Comment by Phill Pafford [ 12/Dec/12 ]

adding html tags for code to display correctly

Comment by Benjamin Eberlei [ 16/Dec/12 ]

DateTimeTz is created as 'TIMESTAMP(0) WITH TIME ZONE' on DBAL. If you have 'TIMESTAMP(6) WITH TIME ZONE' instead, then you have to create your own datatye.

Comment by Phill Pafford [ 17/Dec/12 ]

Why would this be a new data type? I understand how to fix the problem with creating my own data type to handle the formatting issue and would even suggest just overriding the data type with


        Type::overrideType('datetimetz', 'Doctrine\DBAL\Types\VarDateTimeType');
    Type::overrideType('datetime', 'Doctrine\DBAL\Types\VarDateTimeType');

But it's not a new data type, it's a formatting issue.





[DBAL-396] [GH-236] DBAL-200 Missing docs for 1 parameter in Connection::update Created: 11/Dec/12  Updated: 12/Dec/12  Resolved: 12/Dec/12

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

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


 Description   

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

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

Message:

Trivial addition of docs for 1 parameter that was missing in Connection::update. Resolves an open issue so figured it was worth a pull request.



 Comments   
Comment by Benjamin Eberlei [ 11/Dec/12 ]

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

Comment by Fabio B. Silva [ 12/Dec/12 ]

Merged : https://github.com/doctrine/dbal/commit/74c7616132ad82420320e76fa49781ee2f6af532





[DBAL-395] [GH-235] Update links in Readme Created: 30/Nov/12  Updated: 03/Dec/12  Resolved: 03/Dec/12

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

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


 Description   

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

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

Message:

Just updating some broken and old links in the Readme file.



 Comments   
Comment by Benjamin Eberlei [ 30/Nov/12 ]

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

Comment by Fabio B. Silva [ 03/Dec/12 ]

Merged : https://github.com/doctrine/dbal/commit/2e2336a6c1c3dd3897f9419df9675a5fb0a0edda





[DBAL-394] Unsigned integers are not respected by the schema tool for assocations Created: 30/Nov/12  Updated: 03/May/13  Resolved: 01/May/13

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

Type: Bug Priority: Minor
Reporter: Jonathan Ingram Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

Before commenting, I've done so much debugging and searching into this issue and if I missed something major, I apologise.

From what I understand, the ORM doesn't care about unsigned. That's fair enough. That leaves it to DBAL to handle it.

However, it's not possible to successfully use something like the following table without having the schema manager complain.

CREATE TABLE `account` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '(DC2Type:unsigned_integer)',
  `user_id` int(10) unsigned DEFAULT NULL COMMENT '(DC2Type:unsigned_integer)',
  PRIMARY KEY (`id`),
  KEY `IDX_7D3656A461220EA6` (`user_id`)
) ENGINE=InnoDB

In that code, I'm using a custom type "unsigned_integer" that extends the DBAL integer type with this:

    public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        $fieldDeclaration['unsigned'] = true;

        return $platform->getIntegerTypeDeclarationSQL($fieldDeclaration);
    }

The reason for this is because the ORM won't map unsigned ints for me. Combined with this is an event listener for the class metadata. Something like this:

    /**
     * Maps additional metadata.
     *
     * Specifically, if there exist an unsigned integer field, attach the
     * "unsigned" option to it. This is required because the Doctrine ORM does
     * not do this and we are using "UNSIGNED INT"s in our MySQL columns.
     * Without this. the Doctrine Schema Tool will complain about column
     * differences.
     *
     * Note: there is no performance impact in doing this because the class
     * metadata should be cached after the first request.
     *
     * @param LoadClassMetadataEventArgs $eventArgs
     */
    public function loadClassMetadata(LoadClassMetadataEventArgs $eventArgs)
    {
        foreach ($eventArgs->getClassMetadata()->fieldMappings as &$mapping) {
            if (isset($mapping['type']) && UnsignedIntegerType::UNSIGNED_INTEGER === $mapping['type']) {
                if (!isset($mapping['options'])) {
                    $mapping['options'] = array();
                }

                $mapping['options']['unsigned'] = true;
            }
        }
    }

Now, in the example table above, the schema tool will honour the "id" column, however it won't honour the association join column no matter what I do. My attempts include adding an event listener for class meta data as above (basically tricking the ORM) and also adding an event listener for the schema events.

The other day on GitHub there was a commit (https://github.com/doctrine/doctrine2/commit/a27be2fab61b1cfde4d2ecbc729a4a68816fca76) to help with this, but it's still not all working.

Also, comments and issues on the Jira tracker have said how there's legacy code related to "unsigned" and "default", but I can't tell what's legacy and what's allowed, especially when there's a commit like that one above.

By the way, I have found that the simple unsigned field mapping works. E.g.:

    fields:
        counter:
            type: integer
            column: counter
            options:
                unsigned: true

If it helps at all, here's the YAML mapping file for the above table/entity:

Account:
    type: entity
    table: account
    id:
        id:
            type: unsigned_integer
            generator:
                strategy: AUTO
    manyToOne:
        creator:
            targetEntity: User
            joinColumn:
                name: user_id
                referencedColumnName: id # Note: user table id is also unsigned_integer

Is it possible to 1) fix this or 2) let me know if I'm just doing something wrong?

Note: as I said above, I know that Doctrine DBAL and ORM does not care so much for unsigned ints because of portability, etc. but it seems that because of that commit above (24 days ago), there's a half-implememented/legacy solution going on here.

Cheers,
Jon



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

This was fixed in 657a54da

Comment by Gaetan Rousseau [ 03/May/13 ]

This was not fixed. We can use the option "unsigned" for the fields but not the id.

If someone has a solution or if you can fix this, that would be really cool !

Comment by Gaetan Rousseau [ 03/May/13 ]

After some research with a co-worker we've found a solution to our little problem.

To fix this you just have to add these lines in the YamlDriver (Doctrine/ORM/Mapping/Driver/YamlDriver.php) in the function "loadMetadataForClass", line 265 in the 2.3.3 version of Doctrine ORM :

if (isset($idElement['options'])) {
   $mapping['options'] = $idElement['options'];
}

Just before the :

$metadata->mapField($mapping);

And that an example of schema :

Entities\Test:
  type: entity
  table: Test
  id:
    id:
      type: integer
      options:
        unsigned: true
      generator:
        strategy: AUTO
  fields:
    testField:
      type: smallint
      options:
        unsigned: true

With this, the id can be unsigned without using special type of column, and yes just with this little if
It has been tested in more complexes schemas and all is going well.

In fact, maybe it could be interesting to use the function "columnToArray" like it's used for the other fields.
In the two cases you must care about what you put in your "options" section.





[DBAL-393] PEAR install broken Created: 24/Nov/12  Updated: 25/Nov/12  Resolved: 25/Nov/12

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

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

PEAR, Fedora, RHEL



 Description   

When using PEAR install, the "doctrine-dbal" command does not work.

$ pear install doctrine/DoctrineDBAL
downloading DoctrineDBAL-2.3.0.tgz ...
Starting to download DoctrineDBAL-2.3.0.tgz (143,996 bytes)
................................done: 143,996 bytes
install ok: channel://pear.doctrine-project.org/DoctrineDBAL-2.3.0

$ which doctrine-dbal
/usr/bin/doctrine-dbal

$ /usr/bin/doctrine-dbal
PHP Warning: require(Doctrine/Symfony/Component/Console/Helper/HelperSet.php): failed to open stream: No such file or directory in /usr/share/pear/Doctrine/Common/ClassLoader.php on line 164
PHP Stack trace:
PHP 1. {main}() /usr/bin/doctrine-dbal:0
PHP 2. include() /usr/bin/doctrine-dbal:4
PHP 3. Doctrine\Common\ClassLoader->loadClass() /usr/bin/doctrine-dbal:0
PHP Fatal error: require(): Failed opening required 'Doctrine/Symfony/Component/Console/Helper/HelperSet.php' (include_path='.:/usr/share/pear:/usr/share/php') in /usr/share/pear/Doctrine/Common/ClassLoader.php on line 164
PHP Stack trace:
PHP 1. {main}() /usr/bin/doctrine-dbal:0
PHP 2. include() /usr/bin/doctrine-dbal:4
PHP 3. Doctrine\Common\ClassLoader->loadClass() /usr/bin/doctrine-dbal:0

The issue can be fixed by updating file doctrine-dbal.php from:
$classLoader = new \Doctrine\Common\ClassLoader('Symfony', 'Doctrine');
to:
$classLoader = new \Doctrine\Common\ClassLoader('Symfony');
so the Symfony Console package can be used like the PEAR package.xml requires.

NOTE: I did not want to submit a GitHub pull request for this because it seems like it would break your Git and Composer installs






[DBAL-392] Moving entity relationship doesn't move foreign key in mysql table Created: 24/Nov/12  Updated: 23/Dec/12  Resolved: 23/Dec/12

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

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

Mac OSX, mysql 5.5.28, php 5.4.8


Issue Links:
Reference
is referenced by DDC-2161 Moving entity relationship doesn't mo... Resolved

 Description   

This is the copy of bug http://www.doctrine-project.org/jira/browse/DDC-2161 that I've moved here since it's related to the dbal and not the orm.

Basically when you update just the foreign table of a foreign key the constrain doesn't gets updated.



 Comments   
Comment by Benjamin Eberlei [ 24/Nov/12 ]

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

Comment by Alessandro Tagliapietra [ 26/Nov/12 ]

The related pull request is https://github.com/doctrine/dbal/pull/234





[DBAL-391] [GH-233] convertToPHPValue should match convertToDatabaseValue Created: 23/Nov/12  Updated: 26/Nov/12  Resolved: 23/Nov/12

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

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


 Description   

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

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

Message:

convertToPHPValue return resource which is not match default convertToDatabaseValue that not make and change. Change to return content of the resource.



 Comments   
Comment by Marco Pivetta [ 23/Nov/12 ]

Blob field types should be converted to resources:
https://travis-ci.org/doctrine/dbal/jobs/3329007/#L77

Comment by Benjamin Eberlei [ 26/Nov/12 ]

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





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

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

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





[DBAL-389] [GH-232] Problem with sequence names, PostgreSQL and MixedCased schemas Created: 22/Nov/12  Updated: 22/Nov/12  Resolved: 22/Nov/12

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

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


 Description   

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

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

Message:

I''m having problems with a doctrine migration in a pgsql database that has a mixed case schema name.

After some investigation I've found the origin of the problem: when the schema manager is going to list sequences it executes a SQL statement to find the minimun sequence value.

This SQL statement is not quoting the sequence name, so the SQL fails with mixed cased schemas.

This trivial commit resolves this problem. I think it could be backported to stable versions of DBAL.



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

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





[DBAL-388] [GH-231] Update lib/Doctrine/DBAL/Types/BlobType.php Created: 21/Nov/12  Updated: 09/May/13  Resolved: 09/May/13

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

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


 Description   

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

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

Message:

If allow_url_fopen isnt enabled, fopen will return false.



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

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





[DBAL-387] [GH-230] Fixed SQL Server Platform NULL declaration Created: 21/Nov/12  Updated: 25/Nov/12  Resolved: 25/Nov/12

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

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


 Description   

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

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

Message:

Per previous pull request but based on master. SQL server does not use 'DEFAULT NULL' for marking columns as nullable, only 'NULL'.



 Comments   
Comment by Benjamin Eberlei [ 25/Nov/12 ]

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





[DBAL-386] [GH-229] Fixed SQL Server Platform NULL declaration Created: 21/Nov/12  Updated: 25/Nov/12  Resolved: 25/Nov/12

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

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


 Description   

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

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

Message:

In SQL Server, 'DEFAULT NULL' is invalid for allowing a column to be null – the 'NULL' keyword is the only required indicator of nullability.



 Comments   
Comment by Benjamin Eberlei [ 21/Nov/12 ]

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





[DBAL-385] Null need set to NULL in array type Created: 17/Nov/12  Updated: 25/Nov/12  Resolved: 25/Nov/12

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

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


 Description   

When use Array type and NULL value

set null give in database 'N;' (serialise(null))
need NULL



 Comments   
Comment by Benjamin Eberlei [ 25/Nov/12 ]

This would be a BC Break and cannot be done anymore. You can add your own array type that has this behavior.

Comment by Ivan Borzenkov [ 25/Nov/12 ]

It will not be a loss of backward compatibility.
Now if we have an empty array, that is stored serialized NULL, but the default value for NULL instead of N;
On the part of php will not be any differences - the inverse transform is the same, from the database, we combined the two into a single value, the more accurate in terms of DB

Comment by Benjamin Eberlei [ 25/Nov/12 ]

The field might be NOT NULL, that is what might break BC.

Comment by Ivan Borzenkov [ 25/Nov/12 ]

and if field is null?

 

/**
 * @var array $yandexReg
 *
 * @ORM\Column(name="yandexReg", type="array", nullable=true)
 */
private $yandexReg;

Comment by Benjamin Eberlei [ 25/Nov/12 ]

Well in this case it works obviously, however the Type API doesn't have access to that information. Thats why I meant you should build your own array type and override the internal implementation. This is explained in the Mapping Fields Document of ORM and in the Type Documentation of DBAL.





[DBAL-384] Missing TIMESTAMP support Created: 16/Nov/12  Updated: 27/Apr/13  Resolved: 27/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0, 2.1, 2.2, 2.3
Fix Version/s: 2.2.2

Type: Improvement Priority: Minor
Reporter: Harrie Bos Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Attachments: Text File timestamp.patch    

 Description   

Here's a fix to add support for a TIMESTAMP field in the database.



 Comments   
Comment by Florin Patan [ 18/Nov/12 ]

@Benjamin should I create a PR for this on GH?

Comment by Harrie Bos [ 18/Nov/12 ]

I think it should be fixed in one of the next releases

Comment by frank [ 26/Apr/13 ]

this aint working.. further more i used... http://www.doctrine-project.org/jira/secure/attachment/11350/timestamp.patch

which includes a bit more.. like the actual timestamp.php

but still getting error

Could not convert database value "0000000016E2BCF7" to Doctrine Type timestamp. Expected format: Y-m-d H:i:s

500 Internal Server Error - ConversionException

Comment by Benjamin Eberlei [ 27/Apr/13 ]

Please add this as a custom type to your own project if you need it, this is not going to be part of DBAL Core





[DBAL-383] [GH-228] fixed typo for enabling DEFERRED support Created: 15/Nov/12  Updated: 22/Nov/12  Resolved: 22/Nov/12

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

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


 Description   

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

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

Message:

old spelling still supported for BC



 Comments   
Comment by Benjamin Eberlei [ 16/Nov/12 ]

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

Comment by Fabio B. Silva [ 22/Nov/12 ]

Merged : https://github.com/doctrine/dbal/commit/687643741c8a1c444d35b4e319b59bb15e3730e3





[DBAL-382] add foreign key support to the SQLite platform Created: 14/Nov/12  Updated: 07/Jan/13  Resolved: 15/Nov/12

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


 Description   

SQLite supports foreign keys since version 3.6.19:
http://www.sqlite.org/foreignkeys.html

note when implementing this it also makes sense to look into fixing this typo (likely keeping the current version in place for BC):
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php#L325



 Comments   
Comment by Lukas Kahwe [ 15/Nov/12 ]

initial work:
https://github.com/lsmith77/dbal/compare/sqlite_foreign_key_support

Comment by Lukas Kahwe [ 15/Nov/12 ]

typo in the PostgreSQL driver is fixed here:
https://github.com/doctrine/dbal/pull/228

Comment by Lukas Kahwe [ 15/Nov/12 ]

closing in favor of http://doctrine-project.org/jira/browse/DBAL-383 and http://doctrine-project.org/jira/browse/DBAL-370

Comment by Benjamin Eberlei [ 16/Nov/12 ]

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

Comment by Benjamin Eberlei [ 02/Jan/13 ]

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

Comment by Benjamin Eberlei [ 07/Jan/13 ]

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





[DBAL-381] [GH-227] MySql TEXT and BLOB type declarations Created: 14/Nov/12  Updated: 09/Feb/13  Resolved: 09/Feb/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.0, 2.1, 2.2, 2.3
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Minor
Reporter: Benjamin Eberlei Assignee: Alexander
Resolution: Fixed Votes: 0
Labels: blob, clob,
Environment:

OS X 10.8.2, PHP 5.3.18, Nginx 1.2.4 (php through FPM)



 Description   

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

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

Message:

Fixed maximum length of MySql TEXT type declaration, this should be 65535 (2 ^ 16 - 1) in stead of 65532.

Added support for TINYBLOB, BLOB, MEDIUMBLOB and LONGBLOB based on the length of the field, the same way as the clob type declarations are determined.

Added tests to prevent regression.






[DBAL-380] [GH-226] Fix for decimal fields with precision. Created: 12/Nov/12  Updated: 23/Dec/12  Resolved: 23/Dec/12

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

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


 Description   

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

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

Message:

These fields have no spaces in the length, so the 'explode' fails. Omit the space from the code, and it works. Even if there were a space, it would still work, because of the `array_map("trim", ..)`.

arr(7)
[
"cid" => str(2) "11"
"name" => str(6) "nummer"
"type" => str(7) "DECIMAL"
"notnull" => str(1) "1"
"dflt_value" => str(1) "0"
"pk" => str(1) "0"
"length" => str(4) "18,9"
]



 Comments   
Comment by Bob den Otter [ 07/Dec/12 ]

bump

Not trying to be annoying, but I think this is an issue, that can be resolved quickly, without any consequences for other functionality. If it could be squeezed into 2.3.2 or 2.4, i'd be very grateful.





[DBAL-379] [GH-225] Fix SQLServerPlatform adds unique constraint to ADD PRIMARY KEY statement Created: 09/Nov/12  Updated: 12/Nov/12  Resolved: 12/Nov/12

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

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


 Description   

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

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

Message:

Currently when executing an ALTER TABLE statement with SQL Server, the query will be:

This will happen when adding primary keys via ALTER TABLE.

`ALTER TABLE foo ADD PRIMARY KEY (id) WHERE id IS NOT NULL`

should be

`ALTER TABLE foo ADD PRIMARY KEY (id)`






[DBAL-378] [GH-224] default table option not working Created: 08/Nov/12  Updated: 09/Nov/12  Resolved: 09/Nov/12

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of Steffen-99:

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

Message:

  • Fixing issue, key name corrected


 Comments   
Comment by Benjamin Eberlei [ 08/Nov/12 ]

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





[DBAL-377] Rename Table foreignkey not changed Created: 07/Nov/12  Updated: 21/Nov/12

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

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


 Description   

if i want to change a tablename the foreign key doesnt change and i get an error

$config = new Doctrine\DBAL\Configuration();
$conn = Doctrine\DBAL\DriverManager::getConnection($conn, $config);
$sm = $conn->getSchemaManager();
foreach ($sm->listTables() as $table) {
$fromSchema = $sm->createSchema();
$toSchema = clone $fromSchema;
$toSchema->renameTable($table->getName(), str_replace("_new", "", $table->getName()));
$sql = $fromSchema->getMigrateToSql($toSchema, $conn->getDatabasePlatform());
foreach ($sql as $query)

{ $conn->query($query); }

}

##################################################
CREATE TABLE doc_consultant_practice (consultant_id INT NOT NULL, practice_id INT NOT NULL, INDEX IDX_60C69DE344F779A2 (consultant_id), INDEX IDX_60C69DE3ED33821 (practice_id), PRIMARY KEY(consultant_id, practice_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
ALTER TABLE doc_consultant_practice ADD CONSTRAINT FK_60C69DE3ED33821 FOREIGN KEY (practice_id) REFERENCES doc_xml_practice_new (id) ON DELETE CASCADE
ALTER TABLE doc_consultant_practice ADD CONSTRAINT FK_60C69DE344F779A2 FOREIGN KEY (consultant_id) REFERENCES doc_xml_consultant_new (id) ON DELETE CASCADE
DROP TABLE doc_consultant_practice_new
##################################################
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'doc_xml_consultant_new' already exists' in /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/ORM/Tools/ToolsException.php on line 33

PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'doc_xml_consultant_new' already exists in /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/DBAL/Connection.php on line 646

Call Stack:
0.0178 766208 1.

{main}() /PATH/TO/jobs/import.php:0
0.0430 771936 2. require_once('/PATH/TO/jobs/config.php') /PATH/TO/jobs/import.php:7
0.0528 775448 3. require_once('/PATH/TO/jobs/bootstrap.php') /PATH/TO/jobs/config.php:3
0.0623 812680 4. require_once('/PATH/TO/jobs/bootstrap_doctrine.php') /PATH/TO/jobs/bootstrap.php:5
16.7866 16304048 5. Doctrine\ORM\Tools\SchemaTool->createSchema() /PATH/TO/jobs/bootstrap_doctrine.php:70
16.8798 16562624 6. Doctrine\DBAL\Connection->executeQuery() /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/ORM/Tools/SchemaTool.php:90
16.8804 16564080 7. PDO->query() /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/DBAL/Connection.php:646

Doctrine\DBAL\DBALException: An exception occurred while executing 'CREATE TABLE doc_xml_consultant_new (id INT NOT NULL, name VARCHAR(255) DEFAULT NULL, email VARCHAR(255) DEFAULT NULL, lastCommaFirstName VARCHAR(255) DEFAULT NULL, education LONGTEXT DEFAULT NULL, workHistory LONGTEXT DEFAULT NULL, imageStandard VARCHAR(255) DEFAULT NULL, imageWide VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB':

SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'doc_xml_consultant_new' already exists in /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/DBAL/DBALException.php on line 47

Call Stack:
0.0178 766208 1. {main}

() /PATH/TO/jobs/import.php:0
0.0430 771936 2. require_once('/PATH/TO/jobs/config.php') /PATH/TO/jobs/import.php:7
0.0528 775448 3. require_once('/PATH/TO/jobs/bootstrap.php') /PATH/TO/jobs/config.php:3
0.0623 812680 4. require_once('/PATH/TO/jobs/bootstrap_doctrine.php') /PATH/TO/jobs/bootstrap.php:5
16.7866 16304048 5. Doctrine\ORM\Tools\SchemaTool->createSchema() /PATH/TO/jobs/bootstrap_doctrine.php:70
16.8798 16562624 6. Doctrine\DBAL\Connection->executeQuery() /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/ORM/Tools/SchemaTool.php:90

Doctrine\ORM\Tools\ToolsException: Schema-Tool failed with Error 'An exception occurred while executing 'CREATE TABLE doc_xml_consultant_new (id INT NOT NULL, name VARCHAR(255) DEFAULT NULL, email VARCHAR(255) DEFAULT NULL, lastCommaFirstName VARCHAR(255) DEFAULT NULL, education LONGTEXT DEFAULT NULL, workHistory LONGTEXT DEFAULT NULL, imageStandard VARCHAR(255) DEFAULT NULL, imageWide VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB':

SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'doc_xml_consultant_new' already exists' while executing DDL: CREATE TABLE doc_xml_consultant_new (id INT NOT NULL, name VARCHAR(255) DEFAULT NULL, email VARCHAR(255) DEFAULT NULL, lastCommaFirstName VARCHAR(255) DEFAULT NULL, education LONGTEXT DEFAULT NULL, workHistory LONGTEXT DEFAULT NULL, imageStandard VARCHAR(255) DEFAULT NULL, imageWide VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB in /Applications/MAMP/bin/php/php5.3.14/lib/php/Doctrine/ORM/Tools/ToolsException.php on line 33

Call Stack:
0.0178 766208 1.

{main}

() /PATH/TO/jobs/import.php:0
0.0430 771936 2. require_once('/PATH/TO/jobs/config.php') /PATH/TO/jobs/import.php:7
0.0528 775448 3. require_once('/PATH/TO/jobs/bootstrap.php') /PATH/TO/jobs/config.php:3
0.0623 812680 4. require_once('/PATH/TO/jobs/bootstrap_doctrine.php') /PATH/TO/jobs/bootstrap.php:5
16.7866 16304048 5. Doctrine\ORM\Tools\SchemaTool->createSchema() /PATH/TO/jobs/bootstrap_doctrine.php:70



 Comments   
Comment by Manuel [ 07/Nov/12 ]

now i find a way to rename the table
foreach ($sm->listTableForeignKeys($table->getName()) as $foreignKey)

{ $sm->dropForeignKey($foreignKey->getName(), $table->getName()); }

and then rename.
but it is right that the rows doesnt copy?
or is there a was that i can do it?

else this would be a good feature





[DBAL-376] [GH-223] Include customSchemaOptions in column mapping Created: 05/Nov/12  Updated: 14/Jan/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:

This PR adds the customSchemaOptions in the array passed to the type.



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

Solved in DBAL-413





[DBAL-375] Warning "Udefined index dbname" while creating database with oci8 driver Created: 31/Oct/12  Updated: 20/Apr/13

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

Type: Bug Priority: Minor
Reporter: pavel patrin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: dbname, oci8


 Description   

In config specified:

doctrine:
dbal:
driver: "oci8"
host: "localhost"
port: "1521"
dbname: "orcl50"
user: "SYSTEM"
password: "123456"
charset: UTF8

When i create database (with symfony 2, doctrine:database:create), got that error:

=====================================
Could not create database for connection named orcl50
Notice: Undefined index: dbname in /path/to/symfony/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/OCI8/Driver.php line 67
=====================================

If i comment "unset($params['dbname'])" in CreateDatabaseDoctrineCommand.php:54 all works fine.



 Comments   
Comment by Kris Willis [ 13/Nov/12 ]

I'm experiencing the same issue and your fix appears to work for me too; thanks!

Comment by Benjamin Eberlei [ 20/Apr/13 ]

on Oracle CREATE DATABASE is actually a CREATE USER. I am not sure the command should allow to do this.





[DBAL-374] [GH-222] Escape primary field name in create table sql query Created: 30/Oct/12  Updated: 13/Nov/12  Resolved: 13/Nov/12

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

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


 Description   

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

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

Message:

Fixes primary fields name in CreateTableSQL for Abstract Platform



 Comments   
Comment by Benjamin Eberlei [ 13/Nov/12 ]

Only fixed for primary key columns now, the other will be much more messy, requires refactoring.





[DBAL-373] Indexes and uniqueConstraints has been ignored Created: 26/Oct/12  Updated: 20/Apr/13

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

Type: Bug Priority: Minor
Reporter: