Doctrine Project

[DBAL-544] Where's the Query::HYDRATE_BOTH constant?

Thu, 13 Jun 2013 08:21:44 +0000

In the documentation of the the ResultStatement::fetch() function says that we should use the Query::HYDRATE_* constants but that constant does not exist at least not in 2.3.4.

Should I just use PDO::FETCH_BOTH? But if I change the driver to sqlite or whatever is it going to work well?

[DBAL-543] Oracle DSN pooled option in wrong place of TNS connect descriptor and missing in Oracle PDO driver

Wed, 12 Jun 2013 14:01:29 +0000

The DBAL OCI8 driver places the "(SERVER=POOLED)" directive in the wrong place. To illustrate, when the "pooled" option is given to the driver options the following TNS connect descriptor is build:

(
  DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=myhost)(PORT=1521)))
  (
    CONNECT_DATA=(SID=sales)
  )
  (
    SERVER=POOLED
  )
)

However the correct TNS connect descriptor is:

(
  DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=myhost)(PORT=1521)))
  (
    CONNECT_DATA=(SID=sales)(SERVER=POOLED)
  )
)

Also, the pooled option is missing in the PDO Oracle driver.

See this page for more info: http://docs.oracle.com/cd/B28359_01/server.111/b28310/manproc004.htm

[DBAL-464] MySQL fails when try to drop a primary index with Auto Increment

Thu, 14 Mar 2013 14:52:14 +0000

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-423] Type GUID = VARCHAR(255) on platforms that don't have a native GUID support

Fri, 25 Jan 2013 11:03:03 +0000

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

Thu, 24 Jan 2013 01:25:45 +0000

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-411] Schema updater breaks when using backticks in tablenames.

Tue, 8 Jan 2013 11:24:46 +0000

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-406] PostgreSqlSchemaManager::tablesExist() misses schema-qualified table names if they exist in the first schema on the search path

Mon, 7 Jan 2013 08:33:41 +0000

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-400] can't add primary key to mysql table after the table is created

Thu, 20 Dec 2012 07:08:06 +0000

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-375] Warning "Udefined index dbname" while creating database with oci8 driver

Sat, 20 Apr 2013 08:48:22 +0000

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.

[DBAL-373] Indexes and uniqueConstraints has been ignored

Sat, 20 Apr 2013 09:53:26 +0000

I using the Doctrine Migrations and when I declared my entity with the indexes section, the index name has been ignored. It's like this:

indexes:
IDX_ADDRESS_CITY:
columns: city_id

but, the diff tools ignore it and give me this code:
$this->addSql("CREATE INDEX IDX_7299B5238BAC62AF ON tb_address (city_id)");

and it should be:
$this->addSql("CREATE INDEX IDX_ADDRESS_CITY ON tb_address (city_id)");

Notice: I open the same bug on the migrations repository in github and @kimhemsoe told me to open here, since this is generated by DBAL component.

[DBAL-372] Add SQL parser

Thu, 25 Oct 2012 12:52:51 +0000

It is useful for create sql highlighter. See https://github.com/doctrine/DoctrineBundle/pull/117 or https://github.com/doctrine/DoctrineBundle/issues/107

[DBAL-352] Running doctrine:schema:update throws an exception the first time, succeeds the second time.

Tue, 25 Sep 2012 14:35:32 +0000

Shell output from my symfony project:
$ app/console doctrine:schema:update --force
Updating database schema...

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE Tn ADD CONSTRAINT FK_3504C6F07D3656A4 FOREIGN KEY (account) REFERENCES Account (id)':

SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'account' doesn't exist in table

[PDOException]
SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'account' doesn't exist in table

doctrine:schema:update [--complete] [--dump-sql] [--force] [--em[="..."]]

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

[DBAL-319] Doctrine\DBAL\Types\Type

Sun, 12 Aug 2012 18:34:28 +0000

The API could be improved in the next major release:

Type::add() instead of addType()
Type::isRegistered() instead of hasType() (has sounds weird)

Etc.. I think the 'type' in the methods is redundant since Type is already the object I am dealing with.

I'd also like a remove() method to unregister a type at runtime. Would make testing a little easier and I don't have to check with hasType() etc..

[DBAL-318] getSQLDeclaration

Sun, 19 Aug 2012 22:36:37 +0000

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Types/Type.php#L119-L125

Should define a @return type. Otherwise you have to step through other types to figure this out.

[DBAL-297] PDO::PARAM_LOB (value=3) overlaps with PDO::FETCH_NUM (value=3) in OCI8Statement::$fetchModeMap

Thu, 5 Jul 2012 08:13:31 +0000

Hi,

In OCI8Statement, using PDO::FETCH_NUM does not work because the fetch style mapping is overwritten by PDO::PARAM_LOB since the two has the same value (3);

protected static $fetchModeMap = array(
PDO::FETCH_BOTH => OCI_BOTH,
PDO::FETCH_ASSOC => OCI_ASSOC,
PDO::FETCH_NUM => OCI_NUM,
PDO::PARAM_LOB => OCI_B_BLOB,
PDO::FETCH_COLUMN => OCI_NUM,
);

so PDO::FETCH_NUM is mapped to OCI_B_BLOB

[DBAL-293] mysql platform can not choose text type column

Sat, 8 Sep 2012 19:51:48 +0000

getVarcharMaxLength() in DBAL/Platforms/MySqlPlatform.php returns 65535;
So, it never choose "text", choose "mediumtext".

[DBAL-292] Multiple use of named parameter doesn't work

Wed, 23 Jan 2013 22:56:54 +0000

In the example in the documentation http://doctrine-dbal.readthedocs.org/en/2.0.x/reference/data-retrieval-and-manipulation.html#dynamic-parameters-and-prepared-statements there is the following example:

$sql = "SELECT * FROM users WHERE name = :name OR username = :name";
$stmt = $conn->prepare($sql);
$stmt->bindValue("name", $name);
$stmt->execute();

When I try this example using pdo_sqlsrv I get the following error:
PDOException: SQLSTATE[07002]: [Microsoft][SQL Server Native Client 11.0]COUNT field incorrect or syntax error

When I use instead the parameters name1 and name2 the query works as expected.

[DBAL-209] fetchAll should include $types array for executeQuery

Sat, 29 Dec 2012 17:31:21 +0000

The fetchAll function should include a $types parameter since it is utilizing executeQuery.

[DBAL-180] Documentation states that Doctrine 'decimal' (DecimalType) is mapped to PHP 'double', however, string is returned

Thu, 20 Dec 2012 00:31:46 +0000

At http://www.doctrine-project.org/docs/orm/2.1/en/reference/basic-mapping.html#doctrine-mapping-types, it is stated that:

"decimal: Type that maps an SQL DECIMAL to a PHP double."

However, in the commit history, we can see that the casting to a float is removed: https://github.com/doctrine/dbal/commits/master/lib/Doctrine/DBAL/Types/DecimalType.php. Casting to a double is not possible in PHP?This seems to result in a float as well, that is probably why it was removed.

I found this out when using PHP's 'is_double()' function (alias of is_float()) to check whether a decimal property was set or not.

Suggestion is to either:

cast to a double (which seems not possible)
cast to a float (why was this removed?)
do nothing to the code, update documentation that string is returned.

In my check function I guess I will use the is_numeric() function.

[DBAL-179] SQLLogger API improvement: log rows affected

Thu, 10 Nov 2011 11:20:25 +0000

A small suggestion. It is useful in our application to log the affected rows in queries in order to make it easier to trace what queries did what. I think a simple way to enable this in the SQLLogger is to modify the stopQuery() interface to receive an option rowcount parameter.

[DBAL-175] Table comments in Doctrine\DBAL\Schema\Table Object

Mon, 17 Oct 2011 07:03:10 +0000

Should be useful discover the table comments from database schema.

This feature is already available for column comments, but not for table comments

[DBAL-167] Schema comparator doesn't work properly with columnDefinition's

Mon, 16 Jul 2012 06:57:07 +0000

Schema comparator will mostly always return changed properties on columns for entities defined with columnDefinition even they are identical in the DB. This is due to weak low-lever compatibility of SchemaTool#getCreateSchemaSql() and SchemaTool#getSchemaFromMetadata() – the first one doesn't reconstruct columnDefinition, and the other one never supports 'fixed', 'default', cannot determine, whether it is boolean or integer (ex. TINYINT in the DB), etc...

All this results in extremely annoying unnecessary alter-table-change-columns surrounded by dropping and after that re-enabling constrains dependent on those columns.

I mean stuff like this:

symfony2#app/console doctrine:schema:update --dump-sql

...
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A3F92F3E70;
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A37A3ABE5D;
ALTER TABLE es_hotels DROP FOREIGN KEY FK_527F88EE584598A3EE551564;
ALTER TABLE es_hotels CHANGE is_active is_active TINYINT(1) NOT NULL DEFAULT '1', CHANGE checksum checksum CHAR(32) DEFAULT NULL;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A3F92F3E70 FOREIGN KEY (operator_id, country_id) REFERENCES es_countries(operator_id, id) ON DELETE CASCADE;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A37A3ABE5D FOREIGN KEY (operator_id, resort_id) REFERENCES es_resorts(operator_id, id) ON DELETE CASCADE;
ALTER TABLE es_hotels ADD CONSTRAINT FK_527F88EE584598A3EE551564 FOREIGN KEY (operator_id, subresort_id) REFERENCES es_subresorts(operator_id, id) ON DELETE CASCADE;
...

The simple solution would be to fix schema comparator not to signal any changes on columns with columnDefinition properties.
But would be much and much better to add some code to all *SchemaManager#getPortableTableColumnDefinition so they would reconstuct columnDefinition and they would be matched in the schema comparator.

I can do this

[DBAL-150] noSQL Shema Management

Sun, 21 Aug 2011 10:03:45 +0000

I have a few ideas to improve DBAL and ORM management for php:
1. Reading if needed ORM schemas definitions from YAML(existing plugin)
2. Then migration it into the one of NoSQL databases(such as MongoDB or Memcache/MemcacheDB)
3. Creating transactional temporary-changes data layer in NoSQL for a current-changes due the webapp launch and running for each run
4. Periodically migrations of a current changes with migration script into RDB(for example by cron)

So we get:
Fast automatic shemas management(Symphony users - I say you "haha" because you have to do some unuseful things like "doctrine:build-schema" etc)
All advantages of RDB (like JOINS) in a data extraction
Full-independence in data changing due to webapp launch(and no transactions are needed) in the current NoSQL data-layer
Low load to the server because after extration we have a lazy return data into the RDB
In feature a simple caching any fast-changed data into NoSQL

What do you thinking about it?

[DBAL-59] Add support for PDO_CUBRID driver when stable

Mon, 22 Aug 2011 02:50:07 +0000

CUBRID is a relational database focused on high performance web-apps. If the PDO_CUBRID http://pecl.php.net/package/PDO_CUBRID gets stable or betaish anytime we should think about support it.

[DBAL-7] Add support for char fields in the ORM layer

Sat, 17 Sep 2011 21:57:10 +0000

It's not possible to use char fields in the ORM layer.

It should be possible to use something like:

@Column(type="char") or ...
@Column(type="string", fixed=true) or ...
@Column(type="fixedstring")