[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-528] [GH-324] Update SQLServer2008Platform.php (support MS SQL Server type datetimeoffset(6)) Created: 23/May/13  Updated: 23/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 valerio8787:

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

Message:

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






[DBAL-527] [GH-323] Update MasterSlaveConnection.php Created: 22/May/13  Updated: 22/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 ananda-agrawal:

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

Message:

check $this->keepSlave before enforcing master as slave






[DBAL-526] Doctrine\DBAL\Connection::executeQuery changes passed clause Created: 22/May/13  Updated: 22/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: Covie X Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.4.15-pl0-gentoo
doctrine/annotations v1.1.1
doctrine/cache v1.0
doctrine/collections v1.1
doctrine/common 2.4.0-RC2
doctrine/dbal 2.4.0-BETA2
doctrine/doctrine-bundle v1.2.0
doctrine/inflector v1.0
doctrine/lexer v1.0
doctrine/orm 2.4.0-BETA2



 Description   

>> var_dump(get_class($db));

string(24) "Doctrine\DBAL\Connection"

>> var_dump($params);

array(2)

{ [0] => int(18) [1] => int(0) }

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

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

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

array(0) {
}






[DBAL-525] PostgreSQL - getDateTimeFormatString() missing Created: 22/May/13  Updated: 22/May/13

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

Type: Bug Priority: Major
Reporter: Jan Pecek Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: datetime, format, postgresql
Environment:

PostgreSQL Database



 Description   

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






[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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-369] [GH-219] Fix storage of binary data for array and object types Created: 19/Oct/12  Updated: 19/Oct/12

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

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

Message:

serialize() returns binary data (NUL bytes) and not all platforms
handle that in CLOB fields (e.g. PostgreSQL).

This change uses base64 encoding to work around that, and transparently
reads (old) non-base64 data as well.

Fixes DBAL-368






[DBAL-367] Reverse engnering do not work with Oracle DB Created: 18/Oct/12  Updated: 23/Jan/13

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Zelenin Alexandr Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, oracle, schematool
Environment:

PHP 5.3.3-1ubuntu9.10 with Suhosin-Patch (cli) (built: Feb 11 2012 06:21:15)
oci8-1.4.7 as PHP extension builded from pecl repository with instantclient-basic-linux.x64-11.2.0.3.0.zip and instantclient-sdk-linux.x64-11.2.0.3.0.zip
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production



 Description   
$ doctrine orm:convert-mapping --filter="ms$ions" xml .

  [Doctrine\DBAL\DBALException]
  Unknown database type binary_float requested, Doctrine\DBAL\Platforms\OraclePlatform may not support it.

cli-config.php:


use Doctrine\Common\Annotations\AnnotationReader;
use Doctrine\Common\Annotations\AnnotationRegistry;

require_once 'Doctrine/Common/ClassLoader.php';

define('APPLICATION_ENV', "development");
error_reporting(E_ALL);

$classLoader = new \Doctrine\Common\ClassLoader('Doctrine');
$classLoader->register();

$config = new \Doctrine\ORM\Configuration();
$config->setProxyDir(__DIR__);
$config->setProxyNamespace('Proxies');

$config->setAutoGenerateProxyClasses((APPLICATION_ENV == "development"));

AnnotationRegistry::registerFile("Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php");
$reader = new AnnotationReader();
$driverImpl = new \Doctrine\ORM\Mapping\Driver\AnnotationDriver($reader, array(__DIR__ . "/../php/ru/niifhm/bioinformatics/biodb/model"));
$config->setMetadataDriverImpl($driverImpl);

if (APPLICATION_ENV == "development") {
    $cache = new \Doctrine\Common\Cache\ArrayCache();
} else {
    $cache = new \Doctrine\Common\Cache\ApcCache();
}

$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);

$connectionOptions = array(
    'driver'   => 'oci8',
    'host'     => 'host.name',
    'dbname'   => 'db.name',
    'user'     => 'user.name',
    'password' => 'user.password'
);

$em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config);
$platform = $em->getConnection()->getDatabasePlatform();
$platform->registerDoctrineTypeMapping('enum', 'string');

$em->getConfiguration()->setMetadataDriverImpl(
    new \Doctrine\ORM\Mapping\Driver\DatabaseDriver(
        $em->getConnection()->getSchemaManager()
    )
);

$helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
    'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
    'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
));


 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

Formatting





[DBAL-357] Missing way to set types for CAST declaration Created: 04/Oct/12  Updated: 04/Oct/12

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

Type: Improvement Priority: Major
Reporter: Pete Sisson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

For a query such as

x = CASE WHEN id=$1 THEN CAST($2 AS int)

there doesn't seem to be a way to correctly assign the type across multiple platforms. E.g. Postgres required "int" but mysql just requires "unsigned". Attempting to use "int" here with mysql will fail.

The method Doctrine\DBAL\Platforms method getIntegerTypeDeclarationSQL will return something like "INT unsigned" for sql, which also fails.






[DBAL-348] [GH-202] Fixed DBAL-139 Oracle's sequences with NOCACHE Created: 22/Sep/12  Updated: 06/Jan/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 AduroIdea:

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 22/Sep/12 ]

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

Comment by Benjamin Eberlei [ 23/Sep/12 ]

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





[DBAL-333] [GH-193] Add DBAL\TypeAwareObject. Created: 29/Aug/12  Updated: 05/Sep/12

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 Romain-Geissler:

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

Message:

This PR adds a common interface for custom object values that requires some PHP <-> SQL conversions, which allows to specify what DBAL type must be used for conversion.



 Comments   
Comment by Benjamin Eberlei [ 30/Aug/12 ]

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





[DBAL-330] [GH-191] Akiban Driver Implementation that Uses PDO Created: 27/Aug/12  Updated: 11/Dec/12

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

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


 Description   

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

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

Message:

Based on discussion in pull request 188 with @stof, I decided to modify the implementation for Akiban to use the PostgreSQL PDO driver instead of the native PHP client for PostgreSQL.

One piece of functionality that does not work with current version of Akiban is lastInsertId. This is because the implementation of CURRVAL for Akiban requires both schema name and sequence name be provided whereas PostgreSQL only requires sequence name ([relevant source](https://github.com/php/php-src/blob/master/ext/pdo_pgsql/pgsql_driver.c#L360)). I will attempt to get CURRVAL in Akiban implemented to have the same parameters as PostgreSQL.

This causes a few tests to fail in the test suite right now. Is there a way to mark a test as expected to fail for a specific database driver with the test suite? What I did in this pull request is skip any tests that use lastInsertId when testing against the Akiban platform. I'll update these tests to not be skipped when CURRVAL works as expected. Let me know if there is a better way to do that.






[DBAL-327] [GH-188] Akiban driver Created: 24/Aug/12  Updated: 29/Aug/12

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

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

Message:

An initial implementation of a driver for the [Akiban Server](http://www.akiban.com/akiban-server). You will notice in the diff there are some features Akiban does not yet support in its latest release but are planned for future releases.

I wasn't sure if pull request was the best way to start a dialog to get this work accepted or whether the mailing list is more appropriate. Please let me know and I will do as suggested.

I am an engineer at Akiban and am very willing to maintain/improve this driver.



 Comments   
Comment by Benjamin Eberlei [ 27/Aug/12 ]

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

Comment by Padraig O'Sullivan [ 28/Aug/12 ]

Yes, this ticket has been superseded by ticket 330.





[DBAL-325] [GH-186] Added third an optional argument `types` to use prepared statement Created: 18/Aug/12  Updated: 29/Aug/12

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:






[DBAL-324] SchemaManager should first look into comment instead of infer the type first. Created: 17/Aug/12  Updated: 14/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: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using schema tool, Doctrine tries to infer the Doctrine type via the mapped types in Platform.
It should first try to read from the comment; if found, ignore the Database type inference.



 Comments   
Comment by Benjamin Eberlei [ 29/Aug/12 ]

Why is this a bug? Can you say some more about why we need to do this and what error occurs?

Comment by Guilherme Blanco [ 29/Aug/12 ]

This issue is strictly correlated to the commit I've done here: https://github.com/doctrine/dbal/commit/e25c774dde971dc4afd40648e9ccd0af53b34ce9

Mainly, we may have legacy database that we do know how Doctrine should operate. Under this circumstance, we may want to add a comment to the field defining the Doctrine DBAL type.
Even though after doing this, Doctrine still complains (in my situation, a SET column type) that it's unable to handle this column type.

That happens because MySQL Schema Manager (and others) first looks for the column type:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php#L112
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L312
which automatically fails.

But if we first try to look for the commented data type:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L884
And forget about the rest if it finds one definition there, it would allow even unknown data types to be managed instead of forcing to define the DBAL Type compatible.

Comment by Steve Tauber [ 14/May/13 ]

This also applies for a type of yaml.
Example:

/** @Column(type="yaml") */
protected $data = array();

./scripts/doctrine orm:schema-tool:update --dump-sql
ALTER TABLE meta CHANGE data data LONGTEXT NOT NULL;

Very frustrating.... Might be related to http://www.doctrine-project.org/jira/browse/DBAL-42





[DBAL-321] [GH-184] Added INSERT support to dbal QueryBuilder Created: 13/Aug/12  Updated: 14/Aug/12

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 Tim-Erwin:

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

Message:

See also http://www.doctrine-project.org/jira/browse/DBAL-320
Please review and commit as fits.






[DBAL-320] allow SQL QueryBuilder to do INSERTS Created: 13/Aug/12  Updated: 13/Aug/12

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

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

Attachments: Text File INSERT-for-doctrine-SQL-QueryBuilder.patch    

 Description   

With

$db = \Doctrine\DBAL\DriverManager::getConnection($connectionParams, $config);
$qb = $db->createQueryBuilder();

this QueryBuilder I'm able to do SELECT, UPDATE and DELETE. However, INSERT is not possible. Are there any good reasons for this?

Attached you find a patch that until now works fine for me. I don't know, however, if there are any side effects.



 Comments   
Comment by Marco Pivetta [ 13/Aug/12 ]

Insert is not supported by DQL

Comment by Tim Mundt [ 13/Aug/12 ]

Well, that was quick and not helpful. I have read about the QueryBuilder in the ORM package. For some reason with persistence (that other libraries don't have), insert cannot be supported. However, I'm talking about DBAL here. What good reason is there not to support INSERT??

Comment by Tim Mundt [ 13/Aug/12 ]

see previous comment, I'd appreciate some clarification

Comment by Marco Pivetta [ 13/Aug/12 ]

Tim Mundt Ouch, no, it was my fault, sorry.
I confused the project related to the issue.

Comment by Marco Pivetta [ 13/Aug/12 ]

This is actually valid (even the patch, though it needs to adds tests)

Comment by Tim Mundt [ 13/Aug/12 ]

Glad to hear there seems to be no fundamental problem with this. Can I somehow help this patch go into the code? I'm not familiar with the tests here. If you give me some pointer, maybe I can come up with something useful. On the other hand, it could be a good idea for some more involved people to have a look at this before.

Comment by Marco Pivetta [ 13/Aug/12 ]

You'd need to add tests in https://github.com/doctrine/dbal/blob/master/tests/Doctrine/Tests/DBAL/Query/QueryBuilderTest.php (to be included in your patch or in a github pull request)
A Github PR is also the fastest way to get your code reviewed since not everyone visits the issue tracker.

Comment by Tim Mundt [ 13/Aug/12 ]

Here's the PR: https://github.com/doctrine/dbal/pull/184





[DBAL-305] [GH-171] provide transactional interface for EntityManager and Connection Created: 12/Jul/12  Updated: 29/Jul/12

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

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

Message:






[DBAL-300] Updates for Fedora packaging Created: 07/Jul/12  Updated: 24/Nov/12

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

Type: Improvement Priority: Major
Reporter: Shawn Iwinski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Fedora, RHEL



 Description   

I am packaging the DoctrineDBAL PEAR package for Fedora and RHEL (EPEL) and would like to have the following updates:

  • package.xml role for LICENSE changed from "data" to "doc"
  • package.xml role for Doctrine/DBAL/README.markdown changed from "data" to "doc"
  • add some content to Doctrine/DBAL/README.markdown (when building RPM this file throws a warning because it is empty)





[DBAL-294] [GH-163] [WIP] Upsert support protoype. Created: 29/Jun/12  Updated: 04/Jul/12

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

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

Message:






[DBAL-291] [GH-157] interface compatibility Created: 01/Jun/12  Updated: 04/Jul/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


 Description   

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

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

Message:






[DBAL-289] Wrong diff between Oracle 'Date' type and Metadata 'Date' type Created: 30/May/12  Updated: 22/Aug/12

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

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

Oracle Express 11g and doctrine-dbal 2.2.2



 Description   

Hi,
I want to update my schema but I am getting the following error message:

[Doctrine\DBAL\Driver\OCI8\OCI8Exception]
ORA-01442: column to be modified to NOT NULL is already NOT NULL

--dump-sql says:

ALTER TABLE CONSIGNMENTS MODIFY (SDGDATE  DATE DEFAULT NULL);

The current table structure looks like that:

Column Name Data Type Nullable Default Primary Key
SDGDATE DATE Yes NULL

Mapping definition:

/**
 * @ORM\Column(name="SDGDATE",type="date",nullable=true)
 */
private $sdgdate;

I think there is a problem with the comparison between Oracles 'Date' type and the Metadata 'Date' type. I am used to use MySQL as DBMS but our customer uses Oracle. MySQL's 'datetime' and Oracle's 'date' type are store the same data.

I am not sure what should be done here. Because this could lead to confusion for all Oracle user.

Maybe there could be a request to the platform in the Schema Comparator here:

public function diffColumn(Column $column1, Column $column2)
{
    $changedProperties = array();
    if ( $column1->getType() != $column2->getType() ) {
        $changedProperties[] = 'type';
    }
    // ...
}


 Comments   
Comment by Christian Stoller [ 30/May/12 ]

When I put a breakpoint on the second line of the diffColumn method in my IDE and stop there during debugging I have those variable values:

$this				Doctrine\DBAL\Schema\Comparator		
$changedProperties		array[0]		
$column1			Doctrine\DBAL\Schema\Column		
  _type				Doctrine\DBAL\Types\DateTimeType	<-- datetime
  _precision			integer		10	
  _scale			integer		0	
  _unsigned			boolean		0	
  _fixed			boolean		0	
  _notnull			boolean		0	
  _autoincrement		boolean		0	
  _platformOptions		array[0]		
  _comment			string		""	
  _customSchemaOptions		array[0]		
  _name				string		"SDGDATE"	
  _quoted			boolean		0	
$column2			Doctrine\DBAL\Schema\Column		
  _type				Doctrine\DBAL\Types\DateType		<-- date
  _precision			integer		0	
  _scale			integer		0	
  _unsigned			boolean		0	
  _fixed			boolean		0	
  _notnull			boolean		0	
  _autoincrement		boolean		0	
  _platformOptions		array[1]		
  _customSchemaOptions		array[0]		
  _name				string		"SDGDATE"	
  _quoted			boolean		0	

You see that there are different types. But it would be nice if the comparison would say: "Theay are equal - no diff"

Comment by Benjamin Eberlei [ 08/Jul/12 ]

This issue can't be fixed. Doctrine has this type abstraction here which prevents a special case fix here. The solution in this case is obvious, set the type to "datetime" on Oracle.

Comment by Christian Stoller [ 22/Aug/12 ]

Sorry, this issue commes up again.

Shipment:
  type: entity
  fields:
    id:
      type: integer
      id: true
      generator:
        strategy: AUTO
    pickupDate:
      type: date
      column: pickup_date
    pickupTimeFrom:
      type: time
      column: pickup_time_from
  lifecycleCallbacks: {  }

When I update my schema with the above YAML mapping, I always get the following error although I haven't changed anything at the mapping.


C:\projects\xyz\trunk>php app\console doctrine:schema:update --force
Updating database schema...
Der Befehl "stty" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

[Doctrine\DBAL\Driver\OCI8\OCI8Exception]
ORA-01442: column to be modified to NOT NULL is already NOT NULL

C:\projects\osl\trunk>php app\console doctrine:schema:update --dump-sql
ALTER TABLE SHIPMENT MODIFY (pickup_date DATE NOT NULL, pickup_time_from DATE NOT NULL)

Okay, I could change the types to 'datetime', but what if I have to move to MySQL? I just want to store 'date' and 'time', not 'datetime'.





[DBAL-284] [GH-152] add ComparatorInterface to allow custom Comparator implementation Created: 21/May/12  Updated: 22/May/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


 Description   

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

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

Message:






[DBAL-275] Automatically attempt to reconnect a dropped persistent MySQL-connection (MySQL server has gone away) Created: 14/May/12  Updated: 21/Nov/12

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

Type: Improvement Priority: Major
Reporter: Dieter Peeters Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 4
Labels: None
Environment:

doctrine-dbal/2.1.6, driver PDOMySql


Attachments: File doctrine-connection.php     GZip Archive reconnect_layer.tar.gz    

 Description   

For php-scripts that run for a long time (a.o. daemons) persistent connections will almost always be dropped by the MySQL-server after a set timeout (depending on wait_timeout). This will have Doctrine throw an exception and have the php-script terminate if not catched. It is not practical to catch the same Exception with a try-catch around every query.

I have fixed this for DBAL 2.1.6 by adding a custom layer of Statement-, Connection- and Driver classes.
Key functionalities:

  • The custom layer will transparently catch dropped connections and attempt a number of times (configurable) to reconnect.
  • The behaviour will not be triggered in a transaction (in that case it will revert to throwing an exception just like before).
  • The reconnect behaviour is not MySQL specific per se. It can be triggered by any Exception for any Driver-type if a Driver provides a method 'getReconnectExceptions'.
  • Minimal performance-impact. Only when an Exception is thrown will it be searched for a matching Exception to possibly trigger the behaviour. (also the reason a single stringmatch is used)

Why this functionality?

  • It is often not possible to change settings of a database-server.
  • In a production environment the MySQL wait_timeout is often set to mere seconds
  • Doctrine's use of persistent connections will become a little more persistent
  • More reliable and robust php-scripts built on top of the DBAL

See files in attached archive to get an idea of the code. Enabling the layer is currently done like this (Symfony2 yml):
doctrine:
dbal:
wrapper_class: DoP\DoPBundle\Doctrine\DBAL\Connection
driver_class: DoP\DoPBundle\Doctrine\DBAL\Driver\PDOMySql\Driver
options:
x_reconnect_attempts: 2

Maybe I overlook something, but I only see pro's, no cons, to this improvement. I have created this issue to poll if you think this is a welcome feature and are interested to have me rework the code into DBAL itself? Reworking it into DBAL itself would certainly greatly reduce my code.

If agreed I'll create a github pull request when finished with the code and take comments/improvements from there.

(Also, I have glanced over http://www.doctrine-project.org/contribute.html but did not find any coding/testing-guidelines. Can you point me in the right direction?)

Regards,

Dieter



 Comments   
Comment by Nils Adermann [ 24/Aug/12 ]

Sounds like a rather useful addition to me, would be cool to see this as a default feature.

Comment by Julien Pauli [ 13/Nov/12 ]

We used this at work, it's simple, it could need more reflection

Comment by Benjamin Eberlei [ 13/Nov/12 ]

The problem with a generic solution here are the risks involved, we need to answer questions:

1. did a transaction get aborted beccause of this
2. is it safe to continue at this point with a second, new connection

I am not sure we can guarantee the 100% working.

Comment by Dieter Peeters [ 13/Nov/12 ]

@Julien:
I assume you are referring to the elaborated switch-statement? Well, since this is a DBAL I think data-integrity and performance are the more important things. In my experience when performance is important, you avoid reflection in PHP as much as possible. In the light of performance the switch-statement was a very deliberate substitution of a call to call_user_func_array. The number of arguments was finite and I am fairly sure all possible cases where covered.

@Benjamin:
It seems I forgot to mention this in my statement above. Transactions are indeed an issue I deliberately avoided in this early version. As far as I know, transactions in MySQL are connection-based so the transaction will be rolled back when the server disconnects. A solution would be to incorporate a cache of all statements in a transaction. I was waiting on feedback of the Doctrine-developers on incorporating this code into the DBAL itself, before extending it with more functionality... and I now notice that it got assigned

I'll try to answer your two questions:
1. If the connection is dropped when inside a transaction, the behaviour will revert to the normal Doctrine-behaviour, i.e. no reconnection-attempt will be made and the exception 'MySQL server has gone away' will be thrown.
2. To be clear, I always try to write bug-free code, but I do not guarantee anything about this code. To answer your question: yes, it is safe to continue if you try-catch your transaction in your application-code. Upon the exception you reconnect to MySQL and repeat the lost transaction.

And as a last note, this code is just to have a workable solution. I tend to agree with anyone who thinks that the correct place to fix this problem is in the MySQL-client itself.

Dieter

Comment by Benjamin Eberlei [ 13/Nov/12 ]

My idea would be to throw an exception on reconnect like it is done atm, when transactionNestingLevel > 0, and otherwise proceed with doing the reconnect. I am not sure i am missing something here though.

Comment by Dieter Peeters [ 13/Nov/12 ]

@Benjamin: I noticed after commenting that you're the assignee ... and corrected my comment a bit.

Now, if you want I can extend the functionality to support transactions. But I prefer to do this directly into the DBAL, not as a layer on top. The resulting code should be a bit cleaner than this layer now.

What do you think?

*edit*
A bit of crossposting here

The way you suggest is the way this layer is implemented
*edit*

Dieter

Comment by Dieter Peeters [ 13/Nov/12 ]

@Benjamin
It's been a while since I wrote the code. Above answers are from memory. I will revise the code this evening and give you exact answers. Also, related to transactions, I think the way I handle the savepoints should be revised.

Comment by Dieter Peeters [ 13/Nov/12 ]

@Benjamin:
Sorry for the spam...

I couldn't help myself doing a quick verification. The answer to your question lies in the file Connection.php. The method DoP\DoPBundle\Doctrine\DBAL\Connection::validateReconnectAttempt also checks that the transactionNestingLevel < 1, so the method will always return false when in a transaction. I.o.w. when in a transaction no attempt to reconnect will be made and the exception is simply rethrown, as per the default Doctrine behaviour.

Comment by Peter Kruithof [ 21/Nov/12 ]

I could really use this for kong running cronjobs and daemonized scripts. Is this being worked on right now?

Comment by Dieter Peeters [ 21/Nov/12 ]

Peter, you can use the above code, but it only works for statements outside of transactions. Also, the calls for savepoints in transactions need correction. Will do that when I find the time.





[DBAL-273] Allow MasterSlave Connection to switch back to slave Created: 11/May/12  Updated: 11/May/12

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

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





[DBAL-264] Support for UIDs in PostgreSQL Created: 30/Apr/12  Updated: 29/Apr/13

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

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


 Description   

Please add support for uuid datatype in PostgreSQL



 Comments   
Comment by Darrell Hamilton [ 12/Oct/12 ]

It seems the only missing piece is the implementation of the getGuidExpression method in the PostgreSqlPlatform class.

Details on generating UUIDs from postgres can be found here:

http://www.postgresql.org/docs/current/static/uuid-ossp.html

Things that would need to be addressed:

1) It requires the uuid-ossp module to be installed in the database. Solve with documentation or ...?

2) There isn't just one function. Just pick one or make it configurable with a sane default?

Comment by Ross Cousens [ 10/Dec/12 ]

I have implemented this for my own project, using what I think is a sane default:

public function getGuidExpression()

{ return 'uuid_generate_v4()'; }

The other issue I think that needs addressing is that the extension must be loaded into the current database upon creation. Either this is a deal-breaker right here (relying on a PGSQL plugin that's not available by default)

OR

If not, maybe schema:update/create needs to check for whether postgresql is being used, whether there is a guid type/generator being used in an entity, and then either execute CREATE EXTENSION uuid-ossp;, and failing that return an exception that informs the user that uuid-ossp must be available as an extension before GUID generation can be used in entities.

Can someone explain to me please the position on this currently? Is it not ok to rely on non-core/standard functionality?

Comment by Mark Badolato [ 25/Apr/13 ]

Is there any sort of decision on this item? I was trying to use UUID with Postgres and finally got it to work by adding

public function getGuidExpression()

{ return 'UUID_GENERATE_V4()'; }

and went to submit a patch, then found this ticket and see that it's the exact same solution that Ross Cousens submitted above. I'd really like to not maintain my own fork of the repository just to have this change in place, and it seems like a reasonable fix (barring the uuid-ossp extension not being a Postgres default extension). Can we get this in there so it's available, and worry about the issue of informing the user about the extension at a later point?

Or is there an easy way that anyone knows that I can add the function to my own class (in a Symfony2 project) that would extend PostgreSqlPlatform.php and add the function, without the need for me to fork Doctrine and add it on my own?

Thanks,
--mark

Comment by Mark Badolato [ 25/Apr/13 ]

Pull request submitted

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

Comment by Ross Cousens [ 26/Apr/13 ]

I hope this gets accepted but I fear it won't.

The original complaint against implementing GUID for the PostgreSQL platform driver was because a) it required a separate extension to be enabled on the server itself b) and there were a number of GUID generation functions available.

To use anything but v4 would be asinine unless some external constraint was forcing you to use the older generation algorithms, so I think argument b is mostly moot. Argument a can easily be solved with documentation, programmatically as well (would require more work) or just left as is because the error back from postgresql is very verbose. Cannot find function uuid_generate_v4. Google it, see that extension is required, see that it's available in PostgreSQL contrib packages, enable it, and voila it works.

Comment by Mark Badolato [ 26/Apr/13 ]

Agreed, and I think that having SOMETHING that is usable (and has a very clear message that you need to install an extension) is better than nothing. The implementation can be expanded later to cover the extension not existing, or using something other than v4, etc. But this should be good enough for most people and it seems silly not to have, or at least not have a way to override and provide it.

I was looking at the Symfony configs to see if there was a way to define my own platform class that could then just extend the current PostgreSqlPlatform class and add a the function, but that doesn't seem to be doable (or I just missed it)

Comment by Mark Badolato [ 27/Apr/13 ]

I just saw that this got merged into master. As soon as this hits 2.3* I can do away with the manual UUID generation for id's that we're currently doing

Thanks much Benjamin!

Comment by Ross Cousens [ 29/Apr/13 ]

Yay, I am happy that this has been accepted and will make it through to next release. Thank you Mark/Benjamin!





[DBAL-249] Enable caching for fetch type FETCH_COLUMN Created: 05/Apr/12  Updated: 05/Apr/12

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

Type: Improvement Priority: Major
Reporter: Aigars Gedroics Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If results are requested using fetch method FETCH_COLUMN, and the cache is used, the exception is raised:

Invalid fetch-style given for caching result





[DBAL-242] Catch and re-throw exceptions with common messages + codes Created: 24/Mar/12  Updated: 20/Sep/12

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

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





[DBAL-235] Column order is not synchronized by Comparator Created: 08/Mar/12  Updated: 03/Apr/12

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

Type: Improvement Priority: Major
Reporter: Artem Goutsoul Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

MySQL



 Description   

Comparator does not synchronize column order. It would be great if it did.



 Comments   
Comment by Chris Woodford [ 02/Apr/12 ]

I assume that this means adding AFTER to any ALTER ADD statements? if so, this is something that i would really appreciate as well

Comment by Artem Goutsoul [ 03/Apr/12 ]

Yup, that's exactly what I meant!





[DBAL-234] Index names are not synchronized by Comparator Created: 08/Mar/12  Updated: 08/Mar/12

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

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

MySQL



 Description   

Index and foreign key name change is not synced by Comparator.

This is important since in some complex queries one might use FORCE INDEX (some_index_name), and they will fail if an index name is incorrect.






[DBAL-232] Custom commented column type removal causes unknown column type exception Created: 06/Mar/12  Updated: 09/Mar/12

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

Type: Improvement Priority: Major
Reporter: Aigars Gedroics Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Problem happens when initially, as example, there was commented type "foo" registered and used:

Doctrine\DBAL\Types\Type::addType('foo', 'FooType');
$em->getConnection()
    ->getDatabasePlatform()
    ->markDoctrineTypeCommented(Doctrine\DBAL\Types\Type::getType('foo'));

When the type usage and declaration is removed, the database schema upgrade fails.
This is because DBAL reads the comment from the database and tries to find the type 'foo'.

I suggest ignoring the database column comment and stick to the standard type recognition in case the type is not declared.



 Comments   
Comment by Aigars Gedroics [ 09/Mar/12 ]

Trivial solution would be:

--- a/Doctrine/DBAL/Schema/AbstractSchemaManager.php
+++ b/Doctrine/DBAL/Schema/AbstractSchemaManager.php
@@ -878,7 +878,9 @@ abstract class AbstractSchemaManager
     public function extractDoctrineTypeFromComment($comment, $currentType)
     {
         if (preg_match("(\(DC2Type:([a-zA-Z0-9]+)\))", $comment, $match)) {
-            $currentType = $match[1];
+                       if (Types\Type::hasType($match[1])) {
+                               $currentType = $match[1];
+                       }
         }
         return $currentType;
     }




[DBAL-225] Add events for onBeginTransaction, onCommit, onCommitFailure Created: 13/Feb/12  Updated: 20/Sep/12

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

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


 Description   

Allow to switch a CommitFailure into a successful event.

This could be done by saving all insert/update/delete statements starting from begin transaction and then replaying them N-times until success is achieved.






[DBAL-221] Schema toSQL() and toDropSQL() both need to delegete creation/drop of schema-level elements Created: 13/Feb/12  Updated: 20/Sep/12

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

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


 Description   

The following schema-level changes have to be done before tables are created:

  • create Schema (PGSQL, MySQL, ...)
  • Create Federations (Azure)
  • Create Types (PGSQL, Oracle, ...)
  • Create Views, Stored Procedures, Triggers

We should add the following APIs:

array $sql AbstractPlatform::getCreateSchemaAdditionalStatements(Schema $schema);
$object = new SQLObject($sqlUpCommand, $sqlDropCommand);
$schema->addSQLObject($object);





[DBAL-218] Add Object for BulkInsert Abstraction Created: 05/Feb/12  Updated: 20/Sep/12

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

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





[DBAL-217] Introduction Interface for Connection Created: 05/Feb/12  Updated: 20/Sep/12

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

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





[DBAL-215] DoctrineBundle Configuration File Created: 03/Feb/12  Updated: 03/Feb/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: Aaron Scherer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In the DoctrineBundle, there is no support for "master" or "slave", yet the "MasterSlaveConnection" in the new DBAL branch wants both of them in the connection.






[DBAL-182] Insert and Merge Query Objects Created: 18/Nov/11  Updated: 20/Sep/12

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

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


 Description   

We are missing Insert and Merge Query Objects.

See Drupal DBTNG:

Merge: http://drupal.org/node/310085
Insert: http://drupal.org/node/310079



 Comments   
Comment by Benjamin Eberlei [ 18/Nov/11 ]

From the first glance: Drupal API has some problems in that it assumes literal values are the default, which makes working with them simple if no expression is necessary. But inconsistent otherwise.

Implementation Details:

  • Difference compared to QueryBuilder is that these objects are no builders, but actually executors.
  • Don't assume Literals
  • Creation is delegated to Platform (Runtime API of a Vendor)
{conn}
$conn->createInsertQuery();
$conn->createMergeQuery();{conn}

Sample API:

$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->values(array('?', '?'))->(array(1, 2))->execute();
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->params(array(1, 2))->execute(); // values(?, ?) is implicit.
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->params(array('NOW()', '1'))->execute(); // if no "params" set assume execute once.
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->value('foo', 'NOW())->params(array(1))->params(array(2))->execute();
$conn->createInsertQuery($tbl)->fields(array('foo', 'bar'))->select($queryBuilder)->execute();

Merge: I dont know yet:

problem i see here is that people mistake values() for a "safe" method and pass values in there that should be quoted instead.





[DBAL-163] Upsert support in DBAL Created: 10/Sep/11  Updated: 20/Sep/12

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

Upsert support in DBAL (replace, insert into usw..)



 Comments   
Comment by Miha Vrhovnik [ 11/Jun/12 ]

FYI: http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/





[DBAL-162] BeforeInsertID & AfterInsertID emulation workflow, wie bei MDB2 Created: 10/Sep/11  Updated: 20/Sep/12

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

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


 Description   

The following workflow is necessary for portable code to work on all platforms:

$nextId = $conn->nextSequenceId();
$query = "INSERT INTO (id) VALUES (?)";
$conn->executeUpdate($query, array($nextId));
$nextId = $conn->lastInsertId();





[DBAL-156] Github-PR-44 by richardfullmer: [PostgresPlatform] Fixing change detection when a default is removed Created: 21/Aug/11  Updated: 21/Aug/11

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

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

{username}

:

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

Message:

Change detection when the default value is removed from a field is presently broken and produces invalid SQL.

This patch checks to see if a new default value actually exists before adding the SET DEFAULT '';

Uses DROP DEFAULT when the new default value does not exist






[DBAL-155] Github-PR-46 by gnomii: 2.1.x PgSql - Same problem with the master Created: 21/Aug/11  Updated: 21/Aug/11

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

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

{username}

:

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

Message:

Hi,

Sorry, I was not able to merge the branchs with the master I try some methods

Best regards,
Maxime






[DBAL-154] Github-PR-47 by gnomii: 2.0.x PgSql - Same problem with the master Created: 21/Aug/11  Updated: 21/Aug/11

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

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

{username}

:

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

Message:

Hi,

Sorry, I was not able to merge the branchs with the master I try some methods

Best regards,
Maxime






[DBAL-153] Github-PR-48 by phekmat: Added a regression test case for recently fixed PostgreSQLSchemaManager bug Created: 21/Aug/11  Updated: 24/Mar/12

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

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

{username}

:

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

Message:

Regression test for the following change: https://github.com/doctrine/dbal/commit/2434d95aab231273eea8fb555155e9e9c195bcc9



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

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

Comment by Benjamin Eberlei [ 24/Mar/12 ]

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

Comment by Benjamin Eberlei [ 24/Mar/12 ]

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





[DBAL-139] Oracle's sequences with NOCACHE Created: 29/Jul/11  Updated: 08/Nov/12

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

Type: Improvement Priority: Major
Reporter: Augusto Ximenes de Souza Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Hi community,

Today I tried to generate Oracle's sequences with "NOCACHE", but I checked that method "getCreateSequenceSQL" don't accept. Can we improvement this method to allow? Below an example of the sintaxe:

CREATE SEQUENCE seq_test START WITH 1 INCREMENT BY 1 NOCACHE



 Comments   
Comment by Ivan Andric [ 22/Sep/12 ]

Hi,

If cache value is specified then syntax should contain CACHE keyword that follows the value and if value is not specified then it should go without CACHE keyword.
In this case sequence will be created with CACHE value 20 by default.
Min cache value is 2 and for determine max value we should have sequence max value defined which is by default 10^27 for an ascending sequence and -1 for a descending sequence.
Now the max cache value is calculated by the formula (CEIL (MAXVALUE - MINVALUE)) / ABS (INCREMENT).

My Idea is to add cache attribute to Sequence object and then under the previous story, set cache to given value if value is greater than 1 and less than calculation by the given formula.

For nocache,
I would use value of 0 so we will have values in domain (0,1<x<=(CEIL (MAXVALUE - MINVALUE)) / ABS (INCREMENT)).

Some public function will return NOCACHE or CACHE n and that function could be called in getCreateSequenceSQL method from Sequence input parameter.

Anyone have a better idea or I can code this and request pull from my fork?

Comment by Ramon Henrique Ornelas [ 08/Nov/12 ]

Duplicate issue http://www.doctrine-project.org/jira/browse/DBAL-348

Greetings
Ramon Ornelas





[DBAL-131] Remove Static Types Created: 19/Jun/11  Updated: 20/Sep/12

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

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


 Description   

the static types should be removed and made to instances of types that can differ between platforms.

Following reasons:

1. Some vendors already convert values to PHP types, for example integers. Not converting again could save about 15% wall-time for integers for example.
2. Some vendors require different type code, this is currently handled by expensive if checks.
3. If you want to change a type for one vendor but also use another vendor in the same request, then you have a problem currently.
4. If types were platform aware then we could make registering custom types simpler.






[DBAL-125] Add Informix Support Created: 08/Jun/11  Updated: 11/Jun/11

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

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

Linux, Unix & Windows



 Description   

Today exist many customers with Informix 11.50 and they will deveoplment with php+simphony, but doctrine will be an alternative inside the framework but it isn't supported.
My customers can't migration ( they are happy with informix) your application and he need a framework as simphony and an abstration of your environment as Doctrine.
There is a possibility to support Informix in Doctrine?
Thanks and regards

Adolfo Flores
Consultant



 Comments   
Comment by Benjamin Eberlei [ 08/Jun/11 ]

There is a possibility to support Informix, this is described here:

http://www.doctrine-project.org/docs/dbal/2.0/en/reference/supporting-other-databases.html

I don't know informix and never worked with it, if you would volunteer to code this i would be enternelly grateful I could help you with the details of implementation.

I think a working prototype can be implemented in 4-6h of time.

Comment by Adolfo Flores [ 08/Jun/11 ]

good idea, I am an expert in informix database and I may need support in doctrine.

Is there any template to follow? I have read the required structure in the url given, it seems feasible.

What next step?

I am installing Informix, php 5.3 on RHES 5.2 All 32-bit

Regards,

Adolfo

Note: .I have no time basis, so that one week would be a reasonable time for this activity

Comment by Benjamin Eberlei [ 11/Jun/11 ]

I added some more details to the chapter, here is the part:

Implementation Steps in Detail
------------------------------

1. Add your driver shortcut to class-name `Doctrine\DBAL\DriverManager`.
2. Make a copy of tests/dbproperties.xml.dev and adjust the values to your driver shortcut and testdatabase.
3. Create three new classes implementing ``\Doctrine\DBAL\Driver\Driver``, ``\Doctrine\DBAL\Driver\Statement``
and ``Doctrine\DBAL\Driver``. You can take a look at the ``Doctrine\DBAL\Driver\OCI8`` driver.
4. You can run the testsuite of your new database driver by calling "cd tests/ && phpunit -c myconfig.xml Doctrine/Tess/AllTests.php"
5. Start implementing AbstractPlatform and AbstractSchemaManager. Other implementations should serve as good example.

Essentially Driver, Statement are the PDO equivalents of "PDO" and "PDOStatement", they even have the exact same API. OCI8 is a good example to see how it works. If Informix works with PDO then its even simpler, take a look at Doctrine\DBAL\Driver\PDO namespace, you don't need to implement the connection and statement then, just the driver taking care of the configuraiton.

The most complicated thing is to get the Platform and SchemaManager to work. Both are responsible for SQL generation for DDL statements for example. It makes sense to run the phpunit testsuite and fix the bugs when occuring until all tests pass.

Also looking at the platform and schema managers of other databases is a very good help





[DBAL-124] OCI8 Adapter (convertPositionalToNamedPlaceholders) Statemachine doesn't consider comments and strings Created: 20/May/11  Updated: 28/Jun/11

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

Type: Improvement Priority: Major
Reporter: Carsten Hetzel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

SQL statements may contain question marks in strings, inline comments or comment blocks. The current implementation of the method "convertPositionalToNamedPlaceholders()" doesn't consider these implications and falsely replaces them by named bind variables.

Replacement code with example:

<?php
$s = '-- Testkomm?ntar
	select	/* ? *//* ??? */ ?||\'H"al?l"o?\' as "h?""llo" union /* "? Kommentar" \' */
	/* ?" */ select \'/*Hallo\'||to_char( ? ) union select \'--Welt\'
	union--
	select ?';

echo 'In: ' . $s . PHP_EOL;

$bind = 0;
$skip = array( '--' => PHP_EOL, '/*' => '*/', '"' => '"', "'" => "'" );
for( $i = 0; $i < strlen( $s ) /* size of string might change! */; /* yes, no increment here! */ )
{
	// Skipping comments and literals
	foreach( $skip as $begin => $end )
	{
		$matches = substr_compare( $s, $begin, $i, strlen( $begin ) );
		if( $matches !== false && $matches == 0 )
		{
			$pos = strpos( $s, $end, $i+strlen( $begin ) );
			// echo "Found $begin, skipping at $i to $end at $pos" . PHP_EOL;
			if( $pos === false )
			{
				// No more data or illegal statement - anyway: no more replacements!
				// echo "EOD" . PHP_EOL;
				break 2;
			}
			$i = $pos + strlen( $end );
			continue 2; // Ensure we match /*..*//*..*/, '''' or """" - that's why we don't ++$i in the for-loop!
		}
	}
	if( $s[$i] == "?" )
	{
		// Positional to named
		// echo "Replace $bind" . PHP_EOL;
		$r = ':name' . ++$bind;
		$s = substr_replace( $s, $r, $i, 1 );
		$i += strlen( $r );
	}
	++$i;
}

echo 'Out: ' . $s . PHP_EOL;


 Comments   
Comment by Benjamin Eberlei [ 19/Jun/11 ]

This algorithmus is painfully slow. There has to be something better, why do you need to foreach the loop inside the for?

Comment by Carsten Hetzel [ 28/Jun/11 ]

Ok, sent you a PM but I'll put my response here, too:

"Painfully slow" at what circumstances? Benchmarks?

This was meant as an example implementation to show the problems of the current implementation - there's always room for improvement.

And never forget: Premature optimization is the root of all evil! ;-p

You want speed - try this one:

<?php
$sql = '-- Testkomm?ntar
        select  /* ? *//* ??? */ ?||\'H"al?l"o?\' as "h?""llo" union /* "? Kommentar" \' */
        /* ?" */ select \'/*Hallo\'||to_char( ? ) union select \'--Welt\'
        union--
        select ?';

echo 'In: ' . $sql . PHP_EOL;

$map = array();
for( $cnt = 0; $cnt < 1000; ++$cnt )
{
        $bind = 0;
        $s = $sql;

        if( isset( $map[$s] ) )
                continue;

        $strlen = strlen( $s );
        for( $i = 0; $i < $strlen /* size of string might change! */; /* yes, no increment here! */ )
        {
                $c1 = $s[$i];
                $c2 = isset( $s[$i+1] ) ? $s[$i+1] : '';
                if( $c1 == '-' && $c2 == '-')
                {
                        $pos = strpos( $s, PHP_EOL, $i+2 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 2;
                }
                elseif( $c1 == '/' && $c2 == '*' )
                {
                        $pos = strpos( $s, '*/', $i+2 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 2;
                }
                elseif( $c1 == '"' )
                {
                        $pos = strpos( $s, '"', $i+1 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 1;
                }
                elseif( $c1 == "'" )
                {
                        $pos = strpos( $s, "'", $i+1 );
                        if( $pos === false )
                        {
                                break 2;
                        }
                        $i = $pos + 1;
                }
                elseif( $c1 == "?" )
                {
                        // Positional to named
                        // echo "Replace $bind" . PHP_EOL;
                        $r = ':name' . ++$bind;
                        $s = substr_replace( $s, $r, $i, 1 );
                        $rLen = strlen( $r );
                        $i += $rLen;
                        $strlen += $rLen - 1;
                }
                else
                        ++$i;
        }
        $map[$sql] = $s;
}
echo 'Out: ' . $map[$sql] . PHP_EOL;

ATTENTION: Each "break 2;" means, you have an invalid statement! Do, whatever the statement class is supposed to do in this case!

Regards, Carsten





[DBAL-122] Impossible to save data to image/binary/varbinary Created: 16/May/11  Updated: 22/Feb/12

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

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

XAMP, MsSQL-Server 2008, PHP 5.3.x, MS pdo_sqlsrv_vc6_ts.dll



 Description   

When trying to insert a value into a Column with type 'image', 'binary' or 'varbinary' the SQLServer states that this is not possible.
When trying to insert into 'binary' or 'varbinary' the error message is:
=> Implicit conversion from nvarchar(max) datatype to varbinary(max) is not allowed.

When trying to insert into 'image' the error message is:
=> Operand collision: nvarchar(max) is incompatible with image.

Doctrine prepares the image/binary/varbinary column in the statements as nvarchar(max) which is wrong.

The cause of this error is that in the MsSQLPlatform::getVarcharTypeDeclarationSQLSnippet($length, $fixed),
or in the datatype mapping which is to 'text'.

The documentation for the MsSQLServer states following conversions (http://207.46.16.252/de-de/library/ms187928.aspx):

*char => binary/varbinary : Explicit conversion
nchar/nvarchar => image : IMPOSSIBLE

So the solution would be, either to leave the datatype blank or use the char/varchar datatype when saving into image/binary/varbinary, which would cause an extra datatype as those would collide with 'text' I guess.



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

I get the problem, but i don't understand the solutions

Can you explain a bit more?

1. how do i leave a datatype empty? and which one?
2. how do i use char/varchar when saving?

I think this is just a problem of unspecific descriptions

Comment by Martin Weise [ 22/Feb/12 ]

Hi Benjamin

Sorry, for this long delay.
I had a deeper inspection what happens when I persist data into a field of type varbinary(MAX) and I got this (using the SQL profiler):

declare @p1 int
set @p1=NULL
exec sp_prepexec @p1 output,
N'@P1 nvarchar(36),@P2 nvarchar(max),@P3 nvarchar(34)',
N'INSERT INTO mc_dokument_data (id, data, mc_dokument_id) VALUES (@P1, @P2, @P3)',
N'03DDAAD1-4BFA-416B-A0C0-9B8B7148F31C',
N'0x3c3f786d6c20766572736...',
N'mwe3bc2c0da6543d1f48d7c83e64f5c449'
select @p1

But it has to be ( removed '-quotes and @P2 changed to varbinary(MAX) ):

declare @p1 int
set @p1=NULL
exec sp_prepexec @p1 output,
N'@P1 nvarchar(36),@P2 varbinary(max),@P3 nvarchar(34)',
N'INSERT INTO mc_dokument_data (id, data, mc_dokument_id) VALUES (@P1, @P2, @P3)',
N'03DDAAD1-4BFA-416B-A0C0-9B8B7148F31C',
0x3c3f786d6c20766572736...,
N'mwe3bc2c0da6543d1f48d7c83e64f5c449'
select @p1

I am not really sure any more if this is caused from Doctrine or from the 'MS SQL-Server PHP-PDO-Driver 2.0.1' .
But I guess this comes from the driver.
If you can validate this, I will make a bug report to them.

The funny thing is if I do this via executeQuery it works...

$data = unpack("H*" , __some__data__);
$data = '0x'.$data[1];

$em->executeQuery(
    "INSERT INTO mc_dokument_data (id, mc_dokument_id, data)". 
   "VALUES('".$id."' , '" . $documentId . "', " . $data . " )"
);

Hopefully I could clarify my problem.

Regards
Martin Weise





[DBAL-109] Doctrine/DBAL/Platforms/MySqlPlatform.php is missing test coverage around _getCreateTableSQL method Created: 12/Apr/11  Updated: 18/Nov/11

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

Type: Improvement Priority: Major
Reporter: Wil Moore III Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

2.1.0-DEV



 Description   

In "Doctrine/DBAL/Platforms/MySqlPlatform.php", the following methods are public: getShowDatabasesSQL, getCreateDatabaseSQL, getDropDatabaseSQL, getDropTableSQL (easy to test); however, the "_getCreateTableSQL" method is not public.

Is there a specific reason for this difference?

As a result of this method not being tested, there is a "quote" method being called which doesn't exist.

See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L410

The only way at this time to test for this case is to get an error when doing: $table->addOption('comment', '...');

I would suggest making the protected method public so it can be tested. I also suggest moving the options parsing out of _getCreateTableSQL into a helper method...this method seems a bit overloaded.

If agreed, I'm happy to take care of the cleanup. Just wanted to get some feedback on the ideas first.



 Comments   
Comment by Benjamin Eberlei [ 18/Nov/11 ]

This is an improvement





[DBAL-100] Add Drizzle Support Created: 16/Mar/11  Updated: 22/Dec/11

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

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


 Description   

Drizzle is out, we should add support for the Dialect.

http://docs.drizzle.org/mysql_differences.html



 Comments   
Comment by Andreas Streichardt [ 22/Dec/11 ]

i have created some hackish fork and the whole testsuite is working already:

https://github.com/m0ppers/dbal

Still WIP but may be a start. I think the C extension is not really ready yet either. When i find time i will most likely have a look at it.

Comment by Benjamin Eberlei [ 22/Dec/11 ]

Can you branch it into something, like git checkout -bDrizzle then push it to your repo and open a Pull Request? Thats way easier to review and discuss.





[DBAL-96] Make approach towards identifier quoting consistent Created: 26/Feb/11  Updated: 20/Sep/12

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

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

Issue Links:
Duplicate
is duplicated by DBAL-120 MySql platform getAlterTableSQL does ... Resolved
Reference
relates to DBAL-45 Add CLI tool that checks for Reserved... Resolved
is referenced by DBAL-40 Transparent table&column names escaping Open

 Description   
  • Make the use of `` a general approach for explicit quoting of identifiers
  • introduce AbstractPlatform::getRegularSQLIdentifierCase($identifier)
  • Introduce AbstractPlatform::isRegularIdentifier($identifier)
  • Fix Schema Assets not to lower-case, but to check for explicit quoting before.
  • Filter values of identifiers passed to all platform functions when they are used in information schema queries according to `` explicit quoting rules.

Problem: Schema is independent of a vendor, this means we have to pick a behavior, i propose SQL-92

This means:

  • strtoupper() ALL tables, column, index, foreign key names that are not quoted by ``
  • For any Quoted identifiers by `` the case is kept.
  • We can introduce a validator to detect a schema that cannot be implemented with a given vendor platform.

In conjunction with the SQL reserved keywords tickets we can then improve the DatabaseDriver considerably to detect identifier casings






[DBAL-95] Interbase/Firebird support Created: 26/Feb/11  Updated: 12/Mar/13

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

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


 Description   

Implemented support for Interbase/Firebird dialects






[DBAL-81] Add support for auto-commit = NO accross databases Created: 02/Jan/11  Updated: 20/Sep/12

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

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


 Description   

Currently all databases are running in AUTO-COMMIT = Yes Mode. This means that you have to explicitly open a transaction to be able to use transactional features.

There should be support to run in auto-commit = no mode, which means after connect and after each commit a new transaction is opened automatically.






[DBAL-76] PostgreSQL Platform list* SQL code is in need of serious love Created: 12/Dec/10  Updated: 08/Jun/11

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

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


 Description   

The Postgres Schema code is very hard to read and inconsistent across the board. Some use pg_class, some pg_tables. Namespaces /Schema are not always properly checked for. There should be a really unified way on how to approach schema query issues.



 Comments   
Comment by Denis [ 08/Jun/11 ]

I'm not sure what this ticket is about exactly, but...

"Namespaces /Schema are not always properly checked for."

Usually, one would not want to specify them and set the search_path instead. Or are you meaning the schema analysis queries used internally? (If so, yes, it kind of sucks in that case, but note that there are a bunch of *_is_visible() methods, e.g. pg_catalog.pg_table_is_visible(rel.oid) which will strip out invisible schemas directly. This may be simpler than injecting schema references all over the place in that it also processes permissions.)

Also, note that PG has a whole bunch of pg_catalog views, which are available in the information_schema.





Length of a string column cannot exceed 255 (DBAL-62)

[DBAL-69] Varchar definition should automatically switch to CLOB for sizes larger than max varchar length. Created: 27/Nov/10  Updated: 20/Sep/12

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-RC1-RC3
Fix Version/s: 2.4

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In the future we would probably allow arbitrary large sizes here and switch to a CLOB definition automatically if the specifed string length is larger than max length.






[DBAL-58] Schema tool does not see difference between onDelete="NO ACTION" and onDelete="RESTRICT" Created: 11/Aug/10  Updated: 31/Oct/10

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

Type: Improvement Priority: Major
Reporter: Jan Obrátil Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Attachments: File Example.php    

 Description   

If database has ON DELETE CASCADE, schema tool detects change to NO ACTION and RESCRICT.
If database has ON DELETE RESCRICT, schema tool detects change only in case of CASCADE.
If database has ON DELETE NO ACTION, schema tool detect change only in case of CASCADE.

Detecting of changes is done by:
doctrine orm:schema-tool update --dump-sql
and
doctrine orm:validate-schema



 Comments   
Comment by Benjamin Eberlei [ 11/Aug/10 ]

which database version do yo uuse? can you paste an example schema?

Comment by Jan Obrátil [ 11/Aug/10 ]

This is example script with 2 testing entities.

Comment by Jan Obrátil [ 11/Aug/10 ]

I have attached script with two entities.

I have this database version:
$ mysql --version
mysql Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (i486) using readline 6.1

Check line 44. There is CASCADE.
Updating schema by: $ doctrine orm:schema-tool:update

Change CASCADE to NO ACTION
$ doctrine orm:schema-tool:update --dump-sql
ALTER TABLE ArticleItem DROP FOREIGN KEY ArticleItem_ibfk_1;
ALTER TABLE ArticleItem ADD FOREIGN KEY (articleGroupId) REFERENCES ArticleGroup(id) ON DELETE NO ACTION

everything ok, so: $ doctrine orm:schema-tool:update

Change NO ACTION to RESTRICT
$ doctrine orm:schema-tool:update --dump-sql
// no output!!

Change RESTRICT to CASCADE
$ doctrine orm:schema-tool:update --dump-sql
ALTER TABLE ArticleItem DROP FOREIGN KEY ArticleItem_ibfk_1;
ALTER TABLE ArticleItem ADD FOREIGN KEY (articleGroupId) REFERENCES ArticleGroup(id) ON DELETE CASCADE

everything ok, so: $ doctrine orm:schema-tool:update

Change CASCADE to RESTRICT
$ doctrine orm:schema-tool:update --dump-sql
ALTER TABLE ArticleItem DROP FOREIGN KEY ArticleItem_ibfk_1;
ALTER TABLE ArticleItem ADD FOREIGN KEY (articleGroupId) REFERENCES ArticleGroup(id) ON DELETE RESTRICT

everything ok, do: $ doctrine orm:schema-tool:update

Change RESTRICT to NO ACTION
$ doctrine orm:schema-tool:update --dump-sql
// no output!!

So there is no way to update database schema from RESTRICT to NO ACTION and reverse!

Comment by Benjamin Eberlei [ 31/Oct/10 ]

Hm you are right, however for MySQL NO ACTION is the same as RESTRICT as stated by http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html





[DBAL-57] Handling of Quoted Elements Created: 30/Oct/10  Updated: 30/Oct/10

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0.0-BETA4
Fix Version/s: None

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

Issue Links:
Reference
is referenced by DDC-832 Not quoted class name when updating e... Resolved

 Description   

Handling of Quoted Table, Column (etc) names is not as good as it could be. Any input is currently accepted, however it is not processed further and used in conjunction with the platform.






[DBAL-40] Transparent table&column names escaping Created: 05/Aug/10  Updated: 02/Feb/13

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

Type: Improvement Priority: Major
Reporter: Jan Tichý Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 9
Labels: None

Issue Links:
Reference
relates to DBAL-96 Make approach towards identifier quot... Open

 Description   

Hello, I would like to re-open the discussion about automatic transparent escaping of all table/column names sent from DBAL to database. It was already discussed in http://www.doctrine-project.org/jira/browse/DDC-88 without any satisfactory result.

Why do I have to quote any reserved word used in table or column name? Why Doctrine doesn't do this automatically for all table and column
names used in generated SQL queries?

Before you start to explain how complicated it is and what problems you will be faced with, try to look at excellent DIBI database layer - how it acts in this way - it's behaviour is very cool. Unfortunally at the moment the full documentation is in czech only, but here is a brief automatic google-translation to english - http://dibiphp.com/en/quick-start.

My suggestion to Doctrine 2 ORM/DBAL solution is:

1. Developer should never care about any escaping or avoiding any reserved words - it is not his business, the DBAL shoult solve it transparently and safely.

2. So there should be no need and even no possibility to add any quotation chars in @column or @table annotations as well as in DQL queries. ORM layer has nothing to do with escaping, it is all a business of the DBAL layer. Current possibility for manual escaping the names in mentioned annotations is totally wrong and should be discontinued.

3. DBAL should escape ALL table and column names transparently and automatically. There should be ne option to enable or disable the escaping, there is no reason for disabling it.

4. The escaping should be performed just in the final translation of DBAL queries to native SQL query, not earlier. This is the right place to do that.

So what do you think about that?



 Comments   
Comment by Roman S. Borschel [ 05/Aug/10 ]

My point of view (and the reason for the current implementation) is as follows:

  • Using reserved words is bad practice.
  • Quoting everything is like hitting all the SQL with a huge big hammer just to hit the 1% of reserved words (which are again, bad practice), thus overkill.
  • Quoting everything bloats the generated SQL (just to hit the 1% of reserved words which are bad practice to begin with)
  • Quoting everything automatically is like hiding the fact from developers that they use reserved words, thus hiding a bad practice and silently encouraging usage of reserved words in new database schemas. This is not desirable.
  • Quoting reserved words has more effects than simply making the database "accept" that identifier. It affects the case-sensitivity and that in a very inconsistent way across databases and operating systems (See http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html , especially the conclusion). You say there is no reason for disabling it but in fact there are a lot of reasons to do so, so many that it is disabled by default in MDB2 and discouraged to enable it.

So, supporting selective quoting in the name of a (slightly) better interoperability with legacy schemas looked (and still looks) like the best solution for us. The support is limited, explicit, does not require much implementation or overhead and does not unnecessarily bloat the SQL.

There is only one solution for reserved words: not using them. Quoting is a workaround, not a solution and especially not a good one.

ps: I really wish quoting reserved words would not be available in SQL It's not available in most programming languages and noone cares, people just don't use reserved words, because they simply can't.

Comment by Jan Tichý [ 05/Aug/10 ]

Hi Roman, thank you very much for your response! I storngly disagree with most of your points .

There is no doubt that using reserved words is bad practice - FROM THE VIEW OF DATABASE SYSTEM.

But we are discussing about ORM and DBAL. One of the biggest goals of ORM/DBAL is to provide transparent usage of the storage behind the scene. No matter if it is MySQL or PostgreSQL or even maybe something completely diferent.

The ORM/DBAL layer should prevent me from any specifics of particular storage as much as possible. I don't want to remember (and I never should to) that I cannot create entity Order because "order" is reserved word in some weird technology far away from me as ORM programmer.

It is strictly consistent with what you have written above in your PS - "It's not available in most programming languages and noone cares, people just don't use reserved words, because they simply can't" - just consider Doctrine 2 to be another programming language - and there is no real systematic reason in Doctrine 2 itself to prevent developers create entities named "Order".

Here is an analogy - It is the same as if you would say that you cannot use associative arrays in PHP because C-language or Assembler behind PHP doesn't support associative arrays. Yes, they don't support them but it is the responsibility of PHP to provide them. In the same way I don't want to respect this weird limitations of particular RDBMS behind Doctrine 2. This is Doctrine's responsibility to transparently cover the limitation.

Moreover, when list of registered keywords is different from one to the other RDBMS, so the naming of entities is strongly dependent on current database server.

Moreover, when I realize that I have used a registered keyword as lately as an error returns from database engine, not earlier.

I suppose here is probably no risk of SQL injection, but I feel the current Doctrine 2 acting to be "vulnerable" in very similar way, on principle. Simply - you are sending an unescaped piece of SQL query to the database without any warranty what it is. And sometimes it fails, sometimes not. From this view I don't consider overall escaping to be overkill at all, I consider it to be a necessity.

I am strongly convinced that developer working upon DBAL or even ORM layer should never think about such naming limitations and he even shouldn't know anything about reserved words in his particular DBMS.

Now to mentioned problems with case sensitivity. Resulting from the fact that Doctrine 2 entity names are case insensitive I belive that all table definitions and SQL queries comming from Doctrine 2 to database should act as case insensitive too. And that the only practicable way is to normalize (lowercase) all table and column names just on DBAL side before it is passed as SQL query to database.

Jan

Comment by Benjamin Eberlei [ 05/Aug/10 ]

There is actually a very good reason for not quoting. Oracle columns behave differently in their internal structure when escaped.

for example:

/**
  * @column(type="integer")
 */
private $foo;

With quoting it would lead to a column "foo" being lower-cased IN the database and even returned so from resultsets. Without casing it would be a column "FOO". We would essentially need to implement lots of glue code just to get this annoying Oracle feature to work and i think Postgres has the same with lower-cased columns.

Comment by Roman S. Borschel [ 05/Aug/10 ]

@"Hi Roman, thank you very much for your response! I storngly disagree with most of your points"

I guess we can agree to disagree then

@"But we are discussing about ORM and DBAL. One of the biggest goals of ORM/DBAL is to provide transparent usage of the storage behind the scene. No matter if it is MySQL or PostgreSQL or even maybe something completely diferent."

Actually, no, "hiding" the storage completely from the developer is not the goal just as it is not the goal to "hide" SQL. There is an object model on one side and a relational database on the other side. The goal is to provide a mapping between them which is not the same as "hiding" one from the other. In order to create good applications that use ORM technology you need to know both very well, OOP and relational databases. The goal is not to make relational database knowledge "unnecessary". This only results in inefficient use of the databases. The goal is to give people who know both sides equally well a tool to map between the two. Not even "portability" between different relational database vendors is a main goal of an ORM technology, it is just obvious to provide assistance with that as part of the mapping.

@"and there is no real systematic reason in Doctrine 2 itself to prevent developers create entities named "Order".

Noone prevents you from naming domain classes anything you want. Class naming is different from table naming. That the table name defaults to the class name is just that, a default, that can and should be changed if necessary.

@"Moreover, when list of registered keywords is different from one to the other RDBMS, so the naming of entities is strongly dependent on current database server."

Correct, and if you want to create a portable application that works, and will be deployed on, a different set of vendors, you need to have some knowledge of these databases and consider their characteristics. An ORM/DBAL technology does not give you any guarantee for complete and transparent portability between vendors and especially not that it will perform equally well on all of them. The ORM/DBAL technology helps you for the most part in a lot of cases with portability issues but it is no free ticket.

@"I suppose here is probably no risk of SQL injection, but I feel the current Doctrine 2 acting to be "vulnerable" in very similar way, on principle. Simply - you are sending an unescaped piece of SQL query to the database without any warranty what it is. And sometimes it fails, sometimes not. From this view I don't consider overall escaping to be overkill at all, I consider it to be a necessity."

Do not confuse identifier quoting with quoting/escaping of special characters as it is used for security reasons on input. Identifier quoting is absolutely not a necessity, it is a workaround for using otherwise reserved words as schema element names. Speaking of goals, it is neither a "goal" of ORM/DBAL technology to completely remove the possibilities of SQL injections. You can't. It'll always be possible with wrong usage.

@"I am strongly convinced that developer working upon DBAL or even ORM layer should never think about such naming limitations and he even shouldn't know anything about reserved words in his particular DBMS."

And I am strongly convinced that a developer working with a DBAL/ORM should know the underlying databases pretty well.

I think you're really not aware of all the consequences it has across different database vendors to quote every identifier. If not for developers using Doctrine, you cause at least any developer or application pain that does not access the database through Doctrine and is thus feels the full pain of case-sensitivity and mandatory quoting you enforced on the whole schema. Ubiquitious access to the data is actually a strong point of a relational database and it is far from uncommon that the same database is accessed by many parties.

I think the approach taken by DIBI is a bad idea and even worse if there is no way to turn this behavior off. Do they have Oracle or DB2 users? I'm wondering what the sysadmins behind these databases might think if they see this quoting nightmare since to my knowledge this is considered bad practice among them as well.

Yes, we're disagreeing on many points but if you really think identifier quoting is a good idea then you're ignoring a whole lot of prior experience (not only mine).

Comment by Lukas Kahwe [ 05/Aug/10 ]

I was one of the lead developers of MDB2 and we just ran into tons of issues when we overly aggressively did identifier quoting by default. even the option caused lots of headaches. furthermore I agree that the ORM is not about turning an RDBMS into an Object Database, but instead to make a mapping possible. In this vain using reserved words or making all identifiers case sensitive will be a big pain for the people that do work one level lower aka the DBA's. heck even as a developer I frequently work on the DB's command line.

Now as for helping people prevent issues with reserved words. Back then I added some reserved word checking into MDB2_Schema. Obviously its hard to really keep track of all of the different reserved words for all RDBMS. Maybe its possible to work with this guy for this: http://www.petefreitag.com/item/290.cfm This way it could be possible to validate if the names chosen in the models will not cause issues with a certain list of RDBMS.

Comment by Benjamin Eberlei [ 07/Aug/10 ]

Reserved words checking sounds to be a fair compromise!

Comment by Jan Tichý [ 30/Aug/10 ]

Hello, thank you all for your responses.

This helped me understand much about Doctrine 2 basic objectives - especially that it is designed mainly to "make a mapping possible" only, not to be as much as possible transparent layer between database and application. And even if I don't like this conception (because I personally think ORM should provide all such features - like automatic reserved keywords escaping - to make the particular database as transparent as possible), at the same time I fully understand all metioned arguments for doing things in such way. Thank you again.

Comment by Damian Boune [ 17/Jan/11 ]

I would like to state an agreement with the OP.

I understand where there are difficulties in handling reserved words and backtick/quoting, and certainly one should always avoid the use of reserved words in their own schema designs. This is a given when one is able to exert control.

At present I am working on a project in which I am dealing with an outside database where I have no control over the schema, nor am I able to push the remote into making the most sensible changes to their schema. I must live with what they provide.

DBAL presents me with a set of invaluable tools that can not be used as-is, because it lacks the ability to handle quoting when generating schema sql. I'm sure there are some other places where I will find this lacking as well. This is disappointing.

Regardless of what we as developers should do when designing our own schema, we still need to be able to work and play with others who may not follow the same common sense conventions.

Edit:
My temporary quick solution to just "make it work", was to modify AbstractAsset::getQuotedName and force the use of $platform->quoteIdentifier. It did the trick for now until a more suitable solution presents itself.

Comment by Francesco Montefoschi [ 03/Feb/11 ]

"its hard to really keep track of all of the different reserved words for all RDBMS"

That's the main point for me.

Comment by Adrian Rudnik [ 26/Apr/11 ]

@Damian thanks for the hint. I just ran into a similar situation.

Not every project is a startup. I tried to use doctrine2 on a customers database for a small web ui. Well I told them to rename their `iso3166-1` table and `alpha-2` field, then we had a good laugh. We made the mapping possible but i'll remember the one thing i learned: doctrine did not help, guide, prevent or cared at all. It did not even hesitate to spew invalid sql snippets when asked to dump. Its okay for me, but i've expected something more resilient from a DBAL.

Comment by Robert (Jamie) Munro [ 02/Feb/13 ]

What do you mean by "Quoting everything is like hitting all the SQL with a huge big hammer"? Is there a performance hit?

I have always quoted all names when working with PostGres. Not quoting them has always felt like not quoting strings in PHP (e.g. $foo[bar] instead of $foo['bar'] because unless the string is keyword or defined as a constant somewhere, you don't need to (although you will get a "Use of undefined constant" warning). In the early days of PHP, not quoting array keys was common example practise.

Comment by Marco Pivetta [ 02/Feb/13 ]

If you want quoting by default on everything we have a quoting strategy (in ORM) that you can use. I don't think quoting everything by default is a viable solution. Back in `Zend_Db` times this was eating up a lot of performance for no real reason. Users having a clean schema without horrors like columns called `order` or `group` should not be penalized because of users not using valid naming schemes.





[DBAL-31] Move Schema related Creation code from AbstractPlatform to AbstractSchemaManager Created: 04/Jul/10  Updated: 24/Dec/10

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

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


 Description   

Move Schema related Creation code from AbstractPlatform to AbstractSchemaManager



 Comments   
Comment by Benjamin Eberlei [ 08/Aug/10 ]

Scheduled for Beta4

Comment by Roman S. Borschel [ 16/Aug/10 ]

If this task is more complex and requires larger refactorings we can re-evaluate it in a post-2.0 release.





[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-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-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-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-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-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-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: Diego Oliveira Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 12.04 with MySQL 5.5 and PHP 5.4


Attachments: Text File dbal-fixing-373.patch     Text File orm-fixing-373.patch    

 Description   

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.



 Comments   
Comment by Padraig O'Sullivan [ 11/Dec/12 ]

Did you specify an index name in the indexes property for your entity in your PHP file? In this case, you should have something like:

indexes={@Index(name="IDX_ADDRESS_CITY", columns={"city_id"})}

That should result in the correct SQL being generated. If I modify the above to:

indexes={@Index(columns={"city_id"})}

I also get a migration that has SQL with an auto-generated index name.

Comment by Diego Oliveira [ 02/Feb/13 ]

Yes I did specify a name, as you can see:

uniqueConstraints:
    UNIQUE_STATE_SLUG:
        columns: slug
indexes:
    IDX_USER_ADDRESS:
        columns: address_id

I don't try do to it using annotations because I choose do use yaml to describe my entities. I will take a look on the source code to see if I can fix it and send a PR.

Comment by Diego Oliveira [ 02/Apr/13 ]

I already sent this patch to Guilherme Blanco, but I guess he doesn't have time to take a look on it.

I guess my solution it's not ideal, but it solve the problem and can be a base to make a better solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Diego Oliveira the fix doesn't seem too nice with the additional boolean flag.

I would rather like to fix the root cause instead of adding this solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

The issue is tricky, because we cannot just move the index definitions above, they will need the columns, however that directly generates the index in the schema tool. Maybe if the gather join column methods would check if they can add an index already it would work.





[DBAL-372] Add SQL parser Created: 25/Oct/12  Updated: 25/Oct/12

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

Type: New Feature Priority: Minor
Reporter: Martin Hasoň Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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. Created: 25/Sep/12  Updated: 25/Sep/12

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

Type: Bug Priority: Minor
Reporter: Mark A. Hershberger Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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
$



 Comments   
Comment by Christophe Coevoet [ 25/Sep/12 ]

Please run the command with the --dump-sql option instead of --force each time before launching it for real, to be able to see which SQL queries are executed in both cases

Comment by Mark A. Hershberger [ 25/Sep/12 ]

I'm not sure how to roll back the changes so that I can reproduce this.

Comment by Mark A. Hershberger [ 25/Sep/12 ]

Got it after a little poking around with git. Rolling back to a commit in my code before the one given here didn't didn't show this reproduce this.

$ php app/console doctrine:schema:create
ATTENTION: This operation should not be executed in a production environment.

Creating database schema...
Database schema created successfully!

$ git checkout d686a39fb664dca540167e1b3e96ea0ffd67bc00
Previous HEAD position was 0510a59... * First round of Customer-to-Accounts (1:n) mapping done * Start of Customer-to-Tn and Tn-to-Account mapping
HEAD is now at d686a39... * A little debugging for Entity::Customer::hasEntitlement * Add FK for Customer to Tn

$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE Account CHANGE guid guid VARCHAR(255) NOT NULL;
ALTER TABLE Tn DROP FOREIGN KEY FK_3504C6F09B6B5FBA;
DROP INDEX IDX_3504C6F09B6B5FBA ON Tn;
ALTER TABLE Tn ADD tnType VARCHAR(10) NOT NULL, CHANGE account_id customer INT DEFAULT NULL;
ALTER TABLE Tn ADD CONSTRAINT FK_3504C6F07D3656A4 FOREIGN KEY (account) REFERENCES Account (id);
ALTER TABLE Tn ADD CONSTRAINT FK_3504C6F081398E09 FOREIGN KEY (customer) REFERENCES Customer (id);
CREATE INDEX IDX_3504C6F07D3656A4 ON Tn (account);
CREATE INDEX IDX_3504C6F081398E09 ON Tn (customer);
ALTER TABLE Customer CHANGE guid guid VARCHAR(255) NOT NULL, CHANGE authGuid authGuid VARCHAR(255) NOT NULL
mah@debian:~/comcast$ php 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[="..."]]

$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE Account CHANGE guid guid VARCHAR(255) NOT NULL;
ALTER TABLE Tn ADD account INT DEFAULT NULL;
ALTER TABLE Tn ADD CONSTRAINT FK_3504C6F07D3656A4 FOREIGN KEY (account) REFERENCES Account (id);
ALTER TABLE Tn ADD CONSTRAINT FK_3504C6F081398E09 FOREIGN KEY (customer) REFERENCES Customer (id);
CREATE INDEX IDX_3504C6F07D3656A4 ON Tn (account);
CREATE INDEX IDX_3504C6F081398E09 ON Tn (customer);
ALTER TABLE Customer CHANGE guid guid VARCHAR(255) NOT NULL, CHANGE authGuid authGuid VARCHAR(255) NOT NULL

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

$

Comment by Christophe Coevoet [ 25/Sep/12 ]

hmm, the first update seems to miss the addition of the account field, which is done the second time through ALTER TABLE Tn ADD account INT DEFAULT NULL;





[DBAL-319] Doctrine\DBAL\Types\Type Created: 12/Aug/12  Updated: 12/Aug/12

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

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


 Description   

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



 Comments   
Comment by Marco Pivetta [ 12/Aug/12 ]

I don't think those namings are really important.
There's one major change to do, which is to somehow get rid of the staticness of the `Doctrine\DBAL\Types\Type` class, and it is not a simple task.
It would also be interesting to set the type objects manually, such as a database `password` type that does encryption/decryption based on a given service. That cannot be done without staticness right now, which renders two different connections requiring the same functionality but with different parameters very difficult.

Comment by Till [ 12/Aug/12 ]

I agree on the static. But I'd also like the API to be cleaned up and the remove method.





[DBAL-318] getSQLDeclaration Created: 12/Aug/12  Updated: 19/Aug/12

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

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


 Description   

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.



 Comments   
Comment by Christophe Coevoet [ 19/Aug/12 ]

Already fixed in master





[DBAL-297] PDO::PARAM_LOB (value=3) overlaps with PDO::FETCH_NUM (value=3) in OCI8Statement::$fetchModeMap Created: 05/Jul/12  Updated: 05/Jul/12

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

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

N/A



 Description   

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 Created: 20/Jun/12  Updated: 08/Sep/12

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

Type: Bug Priority: Minor
Reporter: Kiichi Kajiura Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by Benjamin Eberlei [ 05/Jul/12 ]

How do you call the schema/platform code?

The code is correct, i think you are using it wrong.

Comment by Kiichi Kajiura [ 19/Jul/12 ]

I don't use it directly.
I use it in my entity class file with annotations.
e.g.
@Mapping\Column(type="text")
@Mapping\Column(type="text", length=65535)





[DBAL-292] Multiple use of named parameter doesn't work Created: 12/Jun/12  Updated: 23/Jan/13

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

Type: Bug Priority: Minor
Reporter: Jürgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

IIS 7.5, MS-SQL-Server 2005, PHP 5.4.0



 Description   

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.



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Are you sure you were using the 2.2.2 version of the ORM? Can you try to reproduce this with the latest master?





[DBAL-209] fetchAll should include $types array for executeQuery Created: 25/Jan/12  Updated: 29/Dec/12

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

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


 Description   

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



 Comments   
Comment by Paweł Nowak [ 29/Dec/12 ]

A proposed fix is available with the following pull request: https://github.com/doctrine/dbal/pull/240





[DBAL-180] Documentation states that Doctrine 'decimal' (DecimalType) is mapped to PHP 'double', however, string is returned Created: 11/Nov/11  Updated: 20/Dec/12

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

Type: Documentation Priority: Minor
Reporter: Menno Holtkamp Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Roel Harbers [ 19/Mar/12 ]

I would strongly suggest to leave the behaviour as-is, and fix the documentation, because of all the trouble associated with floating point and rounding. People use the DECIMAL type to prevent those issues, so having the ORM convert it to floating point again would be pretty bad.

Comment by Patrick McDougle [ 26/Apr/12 ]

I have submitted a pull request on this issue on github. Hopefully the doc will be updated soon so other people don't expect the wrong behavior!

https://github.com/doctrine/orm-documentation/pull/93

Mods, this issue can probably be closed.

Comment by Oleg Namaka [ 24/May/12 ]

Leaving decimal values as strings creates another issue with unnecessary entity updates because old and new same values have different types: old value is always the string type, the new one - decimal. If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity. This is plainly wrong IMHO.

Comment by karlie verkest [ 20/Dec/12 ]

There may be other issues around comparison. I'd rather be comparing numeric types than strings when comparing "decimal" values.





[DBAL-179] SQLLogger API improvement: log rows affected Created: 10/Nov/11  Updated: 10/Nov/11

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

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


 Description   

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 Created: 06/Oct/11  Updated: 17/Oct/11

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

Type: New Feature Priority: Minor
Reporter: Asmir Mustafic Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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 Created: 17/Sep/11  Updated: 16/Jul/12

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

Type: Bug Priority: Minor
Reporter: Dmitry Strygin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None


 Description   

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



 Comments   
Comment by Roderick Schaefer | We handle IT [ 16/Oct/11 ]

I'm having the same issue on my production webserver, but not on the development webserver. I find that odd. It tries to drop all foreign keys and create them again, although without the CHANGE statement you are referring to, Dmitry.

Comment by Benjamin Eberlei [ 09/Jan/12 ]

This maybe fixable by making a hash out of the column definition and saving it into a database comment.

The Foreign Key problem maybe because of an old MySQL version 5.0.x

Comment by Joe Cai [ 16/Jul/12 ]

@beberlei, sounds good to me. any plan of implementing this?





[DBAL-150] noSQL Shema Management Created: 21/Aug/11  Updated: 21/Aug/11

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

Type: New Feature Priority: Minor
Reporter: Alexey Shatunov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

all



 Description   

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 Created: 09/Nov/10  Updated: 22/Aug/11

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

Type: New Feature Priority: Minor
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: None


 Description   

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.



 Comments   
Comment by Esen Sagynov [ 22/Aug/11 ]

Hello, I was recently looking if Doctrene supports CUBRID and found this issue. CUBRID PDO Driver is production-ready now, being used in Yii PHP Framework, for instance.

I am CUBRID Project Manager and would like to know if you plan to elevate this issue up so that we could use Doctrene, too. We also plan to include Doctrene into CUBRID Projects site after it gets official support.

If you need any assistance, let me know. I will be glad to assist you.





[DBAL-7] Add support for char fields in the ORM layer Created: 24/Jan/10  Updated: 17/Sep/11

Status: Open
Project: Doctrine DBAL
Component/s: Drivers, Platforms, Schema Managers
Affects Version/s: 2.1, 2.1.1, 2.1.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Glen Ainscow Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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



 Comments   
Comment by Roman S. Borschel [ 24/Jan/10 ]

I dont think this is worth including in the main distribution. A char does not save much compared to a varchar (1 Byte?) and you already have 2 options to make a char:

  • create your own custom type (i.e. FixedString)
  • Use @Column(..., columnDefinition="CHAR(2)")

IMHO, just use a string type with the length you want: @Column(type="string", length=2). That becomes a varchar with length 2.

Comment by Glen Ainscow [ 24/Jan/10 ]

Ya, it is only 1 extra byte. I'm not sure what to do, I like things as optimized as possible, but I guess I could just use columnDefinition if necessary.

Comment by Glen Ainscow [ 24/Jan/10 ]

Actually, I don't really see any reason not to include the char type.

Comment by Roman S. Borschel [ 24/Jan/10 ]

How about code bloat?

Comment by Glen Ainscow [ 24/Jan/10 ]

How many LoC?

Comment by Guilherme Blanco [ 25/Jan/10 ]

@darkangel Around 40. And lots of conditionals, which decreases efficiency of algorithm.

I vote for FixedString DBAL DataType.

Comment by Roman S. Borschel [ 25/Jan/10 ]

We will not put every special data type someone comes up with in the core library. If we go this route, at the end we have 100+ data types (100+ classes plus a bloated type map) in the core library.

There are at least 2 decent options of making a char already if you care about byte counting (see above).

"Why not?" is not the question to ask for when it comes to new features. If it were, we would include a whole lot of stuff that is useless for 99% of the users. There must be strong arguments for "Why?" and there are none.

If we get 50+ votes on this issue we can talk again.

Comment by Glen Ainscow [ 25/Jan/10 ]

Of course not. I didn't know that char was a special data type (especially since it's supported in DC1.2).

I will use @columnDefinition.

You may close this issue.

Comment by Roman S. Borschel [ 25/Jan/10 ]

No need to become defensive. There is still the chance that demand for this particular type gets very high and that can change things.

Thats why this stays open. Otherwise the next guy would probably just create a duplicate ticket (not sure whether non-owners can reopen other tickets).

Comment by Benjamin Eberlei [ 25/Jan/10 ]

@Glen

The problem with Doctrine 1 and having lots of different data-types is that of maintainability. You have to ensure that all the types work on all supported platforms with each and every version. The more datatypes we support by default the more complex will it be for the Doctrine 2 Core to ensure compability and maintainability in this regard.

For each new platform that we will support all datatypes have to be supported for example, something that might even become impossible for some databases.

Adding a datatype from the user perspective is rather simple though, it has to be tested once and is only about 20-40 LOC. I bet you 100 bucks that soon there will be code-snippets out there on all the different database specific types as a doctrine 2 implemention.

Comment by Glen Ainscow [ 25/Jan/10 ]

@Roman
Not being defensive, I have accepted/respected your decision.

@Benamin
I did think about cross-database compatibility. As far as I know, char is supported by the vast majority (or at least easily simulated). But I understand.

Thanks.

Comment by Dmitry Strygin [ 17/Sep/11 ]

Sorry for party rocking but i think that 'fixed' annotation should be enabled in ORM column definitions.
In this case @Column(type="string", length=4, fixed=true) would result in "CHAR(4)" for MySQL, Oracle and Postgres, Sqlite, and DB2, "NCHAR(4)" for MQSQL. etc... It is much more elegant than that columnDefinition.
It is already supported by DBAL as well as 'default' heartlessly removed (DDC-100) from annotation driver due to bizzare reluctance to deal with proper escaping of values.





[DBAL-200] Connection::update() Created: 10/Jan/12  Updated: 11/Dec/12

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

Type: Documentation Priority: Trivial
Reporter: Jonas Liljestrand Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: documentation


 Description   

missing @param array $data in docblock



 Comments   
Comment by Padraig O'Sullivan [ 11/Dec/12 ]

Resolved by pull request 236:

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





Generated at Fri May 24 09:24:33 UTC 2013 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.