[DBAL-968] SQL Server modifyLimitQuery broken Created: 11/Aug/14  Updated: 11/Aug/14

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

Type: Bug Priority: Critical
Reporter: William Schaller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator, sqlserver
Environment:

SQL Server



 Description   

The recent change to SQLServerPlatform.php @jaylinski:improved sqlserver 'doModifyLimitQuery' select-from pattern broke the ORM Paginator's queries on SQL server.

I investigated, and found that some of the test cases for the SQL Server platform weren't actually correct SQL. Also, there were no test cases that covered what the paginator is doing, so I've written test cases for those. I will open a pull request for this issue.

The modifyLimitQuery method in SQLServerPlatform.php should be fixed to pass the fixed old tests and the new tests.

My concern is that that method is becoming too complex, but that's an issue for another day.



 Comments   
Comment by Marco Pivetta [ 11/Aug/14 ]

I'm gonna cry. Thank you, MSSQL, you make our lives so much "easier"





[DBAL-1057] Connection is not lazy anymore when guessing the platform is necessary Created: 05/Dec/14  Updated: 09/Dec/14

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

Type: Bug Priority: Critical
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 4
Labels: None

Issue Links:
Duplicate
is duplicated by DBAL-1067 mysql: selecting db issue Resolved

 Description   

In DBAL 2.5, many driver can rely on different versions of the platform. Unless the version is explicitly provided, the driver will guess it at instantiation time, killing the lazyness of the connection.
This is a critical issue in any context using DI as it means that injecting the connection into anything else will connect to the server.



 Comments   
Comment by Christophe Coevoet [ 05/Dec/14 ]

Actually, the Connection class itself defers the guessing until the first time the platform is accessed. But many places in DBAL and in the ORM are retrieving the platform and storing it in a property of the class at instantiation time to avoid method calls when they need to access the platform. So this might be much harder to fix

Comment by Steve Müller [ 05/Dec/14 ]

Christophe Coevoet Can we analyze the use cases where retrieving the platform is necessary before actually connecting? I only know the custom type registering so far... Maybe we can defer that somehow?

Comment by Christophe Coevoet [ 05/Dec/14 ]

Steve Müller the issue is that many places in DBAL and the ORM are retrieving the connection before they use it. the Connection class itself in DBAL is already deferring the guessing

Comment by Steve Müller [ 05/Dec/14 ]

Christophe Coevoet I know that. The question is WHY do those defered connections need to access Connection::getDatabasePlatform() without connecting? What are the use cases?

Comment by Christophe Coevoet [ 05/Dec/14 ]

Steve Müller The issue is that all those objects are calling $connection->getDatabasePlatform() in their own constructor to store a reference to it for faster access later (no more method calls). This means that *instantiating* the ORM (or some parts of DBAL) triggers the platform guessing, which connects to the DB. This breaks the lazyness and hurts DI contexts (maybe the ORM will not even be used in this process, but it was instantiated because of being a dependency in a complex object graph).

Comment by Christophe Coevoet [ 05/Dec/14 ]

and the issue is precisely that all these parts of Doctrine are *not* deferring the retrieval of the platform.

Comment by Steffen Brem [ 07/Dec/14 ]

This is causing a lot of issues when using CI servers. Where it is very important that those things are lazy, since you do not have the database configured on most applications that build on a CI server.





[DBAL-818] Fetching identity value from an insert fails with merge replication enabled Created: 20/Feb/14  Updated: 20/Feb/14

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

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


 Description   

The way that the PDOSqlsrv driver fetches the identity value for a freshly inserted record will fail if there are triggers on a table that do a secondary insert on a table that also has an identity column.

This is the case when you set up merge replication in SQL Server. The replication creates a series of triggers on the tables to catch any of the changes made for the purposes of replication and inserts those changes elsewhere.

We have switched to using the native SQLSrv drivers instead to work around this since that uses "SELECT SCOPE_IDENTITY() AS LastInsertId" to fetch the value during the insert command.



 Comments   
Comment by Steve Müller [ 20/Feb/14 ]

I'm not quite sure whether we can fix this is in a reasonable way. See PDO's lastInsertId method in itself is documented to be very inconsistent and behaves differently throughout different drivers and even database versions.

This method may not return a meaningful or consistent result across different PDO drivers, because the underlying database may not even support the notion of auto-increment fields or sequences.

Because of this we do not have tests in our testsuite yet that cover the last insert id topic that work as expected on all drivers.
IIRC the fact that DBAL's implementation for the native sqlsrv driver uses "SELECT SCOPE_IDENTITY() AS LastInsertId" is a workaround to support this feature at all and come around the driver limitation IIRC. This as such is a dirty workaround and should IMO not be relied on for scenarios such as you describe.
I'm not quite sure what the expected behaviour of PDO drivers in general would be concerning triggers on PK columns that do other inserts regarding last insert IDs. IMO this is not a Doctrine bug but rather an unsupported use case or even a driver bug/limitation? Not sure on this.
The only thing we could actually do is implement the same workaround we have in the native sqlsrv driver for the PDO driver. But I would rather not do this for such an edge case scenarion.
But that's just my opinion

Comment by Michael Anthon [ 20/Feb/14 ]

Yes, I agree that any workaround will be a bit of a dirty hack.

The main problem is the PDO driver using @@identity to get the last inserted id, which is pretty much the wrong way to do it in all but the simplest of cases... SCOPE_IDENTITY is there for a reason but won't work when called subsequently since it's run inside an sp_prepexec and will be out of scope anyway (it has to be tacked onto the end of the insert statement as it is in the sqlsrv driver)

There's another piece of code in the SQLSrvConnection that uses this method...

 $sql = "SELECT IDENT_CURRENT(".$this->quote($name).") AS LastInsertId";

That could potentially be used as well and would probably give a more accurate answer but is also subject to race conditions on busy systems.





[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-955] No exception thrown for query error Created: 31/Jul/14  Updated: 26/Oct/14

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

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

SQL Server 2012



 Description   

Consider the following code:

IF OBJECT_ID('tempdb..#TestTable') IS NOT NULL DROP TABLE #TestTable

CREATE TABLE #TestTable
( 
id INT  NOT NULL IDENTITY(1,1) PRIMARY KEY, 
aDate DATETIME2(6) NULL
)

INSERT INTO #TestTable
(
aDate
) VALUES
(
'2014-07-30 08:54:23.000000'
)

SELECT *
FROM #TestTable
WHERE aDate > 2000

Error:

Msg 206, Level 16, State 2, Line 21
Operand type clash: datetime2 is incompatible with smallint

Problem: for this error no DBALexception is thrown

By the way, this does work (but does not affect problem description):

SELECT *
FROM #TestTable
WHERE aDate > '2000'


 Comments   
Comment by Marco Pivetta [ 31/Jul/14 ]

Flip your code example includes no DBAL code: could you also add the PHP wrapping around those SQL statements?

Comment by Steve Müller [ 26/Oct/14 ]

Flip ping.





[DBAL-131] Remove Static Types Created: 19/Jun/11  Updated: 04/Dec/14

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

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-162] BeforeInsertID & AfterInsertID emulation workflow, wie bei MDB2 Created: 10/Sep/11  Updated: 04/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.1
Fix Version/s: 2.6
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-1050] [GH-729] Support for database URLs Created: 26/Nov/14  Updated: 05/Dec/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: drivermanager, dsn, uri


 Description   

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

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

Message:

With a bunch of tests.

Of note:

1. in the case of information present in both URL and "normal" parameters, I'm currently giving priority to the information from the URL; IMO this makes more sense than vice versa (base info would be defined in params, and each developer or environment has a URL that may or may not override that base info, such as charset)
1. the syntax for SQLite is `sqlite:///relativepath.db` or `sqlite://ignoredhost/relativepath.db` for relative, and `sqlite:////tmp/absolutepath.db` or `sqlite://ignoredhost//tmp/absolutepath.db` for absolute paths to the database file (I went back and forth on this, but this way is easier and more consistent; https://github.com/kennethreitz/dj-database-url does the same)
1. extra query params are simply "copied" into `$params` verbatim; makes sense IMO especially considering point number 1



 Comments   
Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DBAL-1073] [GH-742] Take care about mariadb platform Created: 12/Dec/14  Updated: 13/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: detection, mariadb, mysql, platform, version


 Description   

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

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

Message:

Hi,
After upgrading to DBAL 2.5, I got an issue where I could not rename index while migrating because of MariaDB [versioning](http://en.wikipedia.org/wiki/MariaDB#Versioning) which outputs ```10.0.15-MariaDB-1~wheezy ``` as server version.

Because 10.x > 5.7 it loads new features from mysql 5.7 which are not available in mariadb ..



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

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





[DBAL-761] Driver\ResultStatement::fetchAll() returns empty array on a seemingly valid Driver\PDOStatement object Created: 03/Jan/14  Updated: 08/Jan/14

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

Type: Improvement Priority: Minor
Reporter: Dennis Matveyev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, orm, query, schematool
Environment:

Windows 7 64 bit, Zend Server/Studio, PHP 5.4.16,
Server: Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8x



 Description   

I came across a weird issue, where when running:

vendor/bin/doctrine-module orm:schema-tool:update

I would get:

[Doctrine\DBAL\Schema\SchemaException]
There is no column with name 'resource_id' on table 'role_resource'.

But I did have a column with the above name in the above table, so that was a weird message for me. So I traced it all the way to this line of code:

https://github.com/doctrine/dbal/blob/2.4/lib/Doctrine/DBAL/Connection.php#L630

If I remove "->fetchAll()" from that line, I get this object:

object(Doctrine\DBAL\Driver\PDOStatement)#531 (1)

{ ["queryString"]=> string(332) "SELECT COLUMN_NAME AS Field, COLUMN_TYPE AS Type, IS_NULLABLE AS `Null`, COLUMN_KEY AS `Key`, COLUMN_DEFAULT AS `Default`, EXTRA AS Extra, COLUMN_COMMENT AS Comment, CHARACTER_SET_NAME AS CharacterSet, COLLATION_NAME AS CollactionName FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'loginauth' AND TABLE_NAME = 'role_resource'" }

Which has a valid SQL query that runs fine and shows Field names on my local machine's MySQL prompt. But when I add ->fetchAll() back in that line of code, an empty array is returned, field names are not returned, and a SchemaException is generated. I found this odd and wanted to report it. Whether it is a bug or not, hopefully I can find the cause of this issue.

For loads more info, please see this: http://stackoverflow.com/questions/20907491/doctrine-2-there-is-no-column-with-name-columnname-on-table-table



 Comments   
Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev It seems you are using MySQL. Can you please tell which version you use?

Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev Please also provide whether you use mysqli or PDO_MYSQL.

Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev Sounds dumb, but also are you sure that the vendor/bin/doctrine-module orm:schema-tool:update uses the correct connection parameters and does not by error connect to another database server or something? Because otherwise everything looks good IMO.

Comment by Dennis Matveyev [ 07/Jan/14 ]

Yes, I am using:
Server version: 5.5.23-log MySQL Community Server (GPL)
mysql client Ver 14.14 Distrib 5.5.23, for Win32 (x86)

Doctrine connection string for 'driverClass' is 'Doctrine\DBAL\Driver\PDOMySql\Driver', so it is PDO_MYSQL.

I am connecting to the right database, but your last suggestion is what helped to uncover the issue. When connecting to the database with the very same user/pass, and running the command, here is what I saw:

mysql> select resource_id from role_resource;
ERROR 1142 (42000): SELECT command denied to user 'login'@'localhost' for table 'role_resource'

Running a GRANT command to allow SELECT for this user solved the problem.

To improve debugging of similar issues, I'd see if there is a way to propagate the error from MySQL server to ./doctrine-module,
or
improve the error message of SchemaException, to i.e. "There is no column with name 'action_id' on table 'role_action', or database permissions prevent table access."

Thanks!

Comment by Steve Müller [ 07/Jan/14 ]

Dennis Matveyev Thank you for reporting this and I'm glad I could help. I will mark this as improvement, though. You are right in that the root cause of the error should be propagated to the user instead.

Comment by Steve Müller [ 08/Jan/14 ]

Dennis Matveyev Okay I found the root cause of the problem. See what MySQL states about access to the information_schema table for retrieving metadata about a certain database:

Each MySQL user has the right to access these tables, but can see only the rows in the tables that correspond to objects for which the user has the proper access privileges. In some cases (for example, the ROUTINE_DEFINITION column in the INFORMATION_SCHEMA.ROUTINES table), users who have insufficient privileges will see NULL.

So it returns NULL instead of raising an error and this is why Doctrine is not able to propagate the proper exception in this case. I'm not sure if changing the exception message in the SchemaException class is the proper way of handling this. Also please note that this is not only about columns (where you got stuck at) but can occurr for almost every list*() action called in the SchemaManager I suppose. Furthermore this might be a MySQL specific issue, not sure about that.

The proper solution would be to throw an exception much earlier, to have a decent behaviour in such an edge case. I think we should throw an exception here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L267 because a table cannot live without columns and indicates an error somewhere. But I would like to hear the opinion of Benjamin Eberlei on that issue.

Comment by Steve Müller [ 08/Jan/14 ]

I checked the SQL Server documentation and it seems they behave exactly the same: http://technet.microsoft.com/en-us/library/ms187113.aspx

In SQL Server 2005 and later, the visibility of metadata is limited to securables that a user either owns or on which the user has been granted some permission. For example, the following query returns a row if the user has been granted a permission such as SELECT or INSERT on the table myTable.

However, if the user does not have any permission on myTable, the query returns an empty result set.





[DBAL-858] oracle IN statement with more than 1000 values Created: 11/Jan/13  Updated: 01/Apr/14

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

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


 Description   

If I have a query with a IN statement with more tahn 1000 values I get an sql error.

I've try IN with implode:
select * from test where id IN(' . implode(',', $values) . ')
and I've also try with executeQuery:
select * from test where id IN(:test)
executeQuery($sql, array($values), array(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY))



 Comments   
Comment by Marc Drolet [ 11/Jan/13 ]

Here is the way I've implement the solution on my side: (for oracle)

into Doctrine/DBAL/Statement.php, I've add this method:

/**
     * Binds a parameter value to the statement.
     * This is implemented this way for oracle only. Other drivers are redirected to bindValue method.
     *
     * The value will be bound with to the type provided (that required to be a table type).
     *
     * @param String $name The name or position of the parameter.
     * @param Array $value The value of the parameter.
     * @param String $type The name of the type to use to bind.
     * @return boolean TRUE on success, FALSE on failure.
     */
    public function bindList($name, Array $value, $type)
    {
        if ('oracle' !== $this->platform->getName())
        {
            $this->bindValue($name, $value, $type);
        }
        else
        {
            return $this->stmt->bindList($name, $value, $type);
        }
    }

into Doctrine/DBAL/Driver/Statement.php I've add:

/**
     * @TODO: docs
     */
    function bindList($param, Array $values, $type);

into Doctrine/DBAL/Driver/OCI8/OCI8Statement.php I've add this method:

/**
     * {@inheritdoc}
     */
    public function bindList($param, Array $value, $type)
    {
        if (!($list = oci_new_collection($this->_dbh, $type)))
        {
            //throw new OCI8Exception::fromErrorInfo($this->errorInfo());
        }

        foreach ($value as $entry)
        {
            $list->append($entry);
        }
        if (!oci_bind_by_name($this->_sth, $param, $list, -1, OCI_B_NTY))
        {
            //throw new OCI8Exception::fromErrorInfo($this->errorInfo());
        }
    }

// NOTE: we should probably add the bindList to all driver Statement object.

into your code you can use it this way:

$sql = "
    SELECT *
    FROM test
    WHERE id IN
    (
        SELECT *
        FROM
        (
            CAST (: p_ids AS list_int_type)
        )
    )
";
$stmt = connection->prepare($sql);
$stmt->bindList(': p_ids', $ids, 'list_int_type');
$stmt->execute();
$rs = $stmt->fetchAll(PDO::FETCH_ASSOC);

NOTE:
list_int_type need to be a valid oracle data type. You can create one with the name you want.
example:
you can have 2 type of accepted array of values: integer and string
let's say we create one for string named: list_str_type and one for integer list_int_type

create or replace type list_str_type as table of varchar2(4000);
create or replace type list_int_type as table of number;

Comment by Benjamin Eberlei [ 01/Apr/13 ]

Hey Marc Drolet

thanks for the feedback and the solution, however i would like to have something generic that is working independent of the database driver. This code is very specific.

Can you point me to some documentation why oci collection works with more than 1000 elements and how it works in PHP?

Comment by Marc Drolet [ 02/Apr/13 ]

Hi Benjamin,

The limitation is not from the oci driver, it's an oracle limitation. There are a couple of possible solution/implementation that can be done but the one I've provide is the one that perform better for the test I've done and from what I can found over the blogs I've read.

I can't find the exact documentation of oracle. oracle doc is so poor.
Here is the best description link I can provide that describe some possible implementation.
http://vsadilovskiy.wordpress.com/substituting-a-collection-for-in-list-performance-study/

I don't know if there is similar limitation with other database. With the implementation I've provided, It will be possible to implement the proper solution depending on the database limitation you face otherwise it will execute the generic IN. What's bad, we need to create the type into the database.

NOTE: In my case, I can not perform a sub-query, I get the my collection from a web service call.





[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: 3
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-879] Sequence default value [PGSQL] Created: 29/Apr/14  Updated: 26/Oct/14

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

Type: Bug Priority: Minor
Reporter: Mohammad Niknam Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: autoincrement, postgresql, sequence
Environment:

ArchLinux
PostgreSQL 9.3.4



 Description   

Hi
I'm using dbal to generate schmea from database via Schema-Manager. The problem is that my primary field 'id' have default value of 'nextval('test1_id_seq'::regclass)' but when I retrive columns using Doctrine\DBAL\Schema\AbstractSchemaManager::listTableDetails() or Doctrine\DBAL\Schema\Table::getColumns() , default value of the column 'id' is null.
In Doctrine\DBAL\Schema\PostgreSqlSchemaManager::_getPortableTableColumnDefinition() method at line 292 default value replaced with null, I don't know why but I guess It's because Driver compatibility.
Also Doctrine\DBAL\Schema\Sequence has no method to retrieve that table.
So I don't have the default value (pointing at sequence) and I can't find out what Sequence is linked to this table either.



 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Can you please provide a code example of how you create table + sequence and retrieve it?





[DBAL-933] Get Statement Column Metadata Created: 05/Jul/14  Updated: 06/Jul/14

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

Type: New Feature Priority: Trivial
Reporter: Benoît Burnichon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be nice to have a utility method in \Doctrine\Dbal\Driver\ResultStatement to properly retrieve the result column names.

Currently, we have to rely on somthing like
$columnNames = array_keys($statement->fetch(\PDO::FETCH_ASSOC));

Problem: It does not work with empty result-sets, and more checks should be performed to handle these.

With PDO, http://www.php.net/manual/en/pdostatement.getcolumnmeta.php could be used to properly retrieve names.

For Sqlite3 it is easy, http://www.php.net/manual/en/sqlite3result.columnname.php

For Mysql, http://www.php.net/manual/en/mysqli-result.fetch-fields.php would do the trick






[DBAL-1054] Expose native database handler from Connection Created: 03/Dec/14  Updated: 03/Dec/14

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

Type: Improvement Priority: Trivial
Reporter: Davide Romanini Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

DBAL drivers totally hide the wrapped native connection handler. Sometimes it is useful having a way to access it, eg: integrating old non-dbal code sharing the same connection, or to access specific funcionalities not available through the driver.
With oci8 for example I'd want to use oci_set_client_info/oci_set_module_name/oci_set_action on postConnect for better dba auditing and analysis. In current implementation the only way is to use reflection and access the protected $dbh instance variable, that's very fragile.
I propose to add a Connection::getNativeConnection() or similar name for this purpose and trivially implement it on the various drivers. BC compatibility could be an issue here, but eventually it could be factored in a more specific interface.



 Comments   
Comment by Steve Müller [ 03/Dec/14 ]

Davide Romanini which Connection are you refering to? The DBAL Connection class provides a getWrappedConnection() method which returns the underlying driver connection object.
If you refer to driver connections in the first place I doubt we will expose the internal connection ressource to avoid possible weird side effects. We had similar discussion several times now. If you need advanced access to driver specific functionality on the connection, please don't use DBAL. DABL is about abstraction accross different drivers and database vendors. It is not intended for advanced driver specific usage.

Comment by Davide Romanini [ 03/Dec/14 ]

getWrapperConnection() returns the DBAL specific connection (OCI8Connection in my use case). That is not a real "native" connection since it is a mere wrapper around the oci8 php module. In particular it doesn't allow to access some specific functions such as:

  • oci_set_action / oci_set_module_name / oci_set_client_info
  • oci_set_prefetch
  • ... other useful functions
    In my case I'm creating a listener that uses the first functions on the list to useful contextual values (eg: symfony controller/action names) to allow fine tuning and monitoring at the dba level. Obviously this is implemented as a cross-cutting concern with a listener without even touching the main application code. So your advise to not using DBAL for such a purpose seems impractical at best.
    Probably a cleaner solution could be to fully encapsulate all the oci8 functions in the OCI8Connection wrapper, creating a real "native" connection. But this is an hard effort, so my approach is more pragmatic.
    I really don't see the whole point of avoiding to "expose the internal connection ressource to avoid possible weird side effects". As a developer I should in any case know what I'm doing and especially when gradually migrating old oci8-based code sharing the same connection is the best approach in my experience. As a side note, improper use of a Connection::getNativeConnection() is just as harmful at least as improper use of EntityManager::getConnection().




[DBAL-1058] It seems that MSSQL syntax was changed Created: 05/Dec/14  Updated: 05/Dec/14

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

Type: Bug Priority: Blocker
Reporter: man4red Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, sqlserver

Issue Links:
Reference
is referenced by DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Open
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Open

 Description   

I'm using dblib, MSSQL (2012).
So, problem is here:

doctrine-module orm:schema-tool:update --dump-sql

Doctrine\DBAL\Driver\PDOException: SQLSTATE[HY000]: General error: 20018 Invalid object name 'SYS.SCHEMAS'. [20018] (severity 16) [SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')] in /var/www/domains/internal.dc.hayas.ru/data/partners.zf2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 106

So it seems, that problems is here:

Doctrine\DBAL\Platforms\SQLServerPlatform.php
At Line 1036

    public function getListNamespacesSQL()
    {
        return "SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

SQL Server >= 2005 uses sys.schemas (lowercase)

Maybe need to add to SQLServer2005Platform.php

SELECT name FROM sys.schemas ...

and also at line 1028 SQLServerPlatform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

add to SQLServer2005Platform.php

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM sys.databases';
    }


 Comments   
Comment by Steve Müller [ 05/Dec/14 ]

man4red thanks for reporting. I'll have a look at it this evening. Weird that the functional tests pass though in my setup :S

Comment by Marco Pivetta [ 05/Dec/14 ]

Steve Müller please note that he is using dblib, which (afaik) we do not officially support.

Comment by man4red [ 05/Dec/14 ]

I've checked by direct query to SQL via SQL Management Studio.
Got multiple servers with a diffirent versions.

Here some test

QUERY:

 SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys') 

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) FAIL
11.0.5058 (SQL Server 2012) FAIL

QUERY:

SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

I've tested on 5 servers 11.0.5058 (SQL Server 2012).
QUERY:

SELECT name FROM SYS.SCHEMAS WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')

Failed on each of them

Other tests:

QUERY:

SELECT * FROM SYS.DATABASES

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

QUERY:

SELECT * FROM sys.databases

9.0.5069 (SQL Server 2005 Service Pack 4) PASS
10.50.4000.0 (2008 R2 SP2) PASS
11.0.5058 (SQL Server 2012) PASS

by the way - is it neccessary to query * from SYS.DATABASES ?

Doctrine\DBAL\Platforms\SQLServerPlatform.php

Line 1030

    public function getListDatabasesSQL()
    {
        return 'SELECT * FROM SYS.DATABASES';
    }

Maybe need to query only names? (name field)
Just asking

Comment by man4red [ 05/Dec/14 ]

According to tests I've added next code to SQLServer2008Platform.php

    /**
     * {@inheritDoc}
     */
    public function getListNamespacesSQL()
    {
        return "SELECT name FROM sys.schemas WHERE name NOT IN('guest', 'INFORMATION_SCHEMA', 'sys')";
    }

And modified my ZF2 application doctrine config config/autoload/doctrine.local.php (platform added):

return array(
    'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'class to work with dblib',
                'params' => array(
                    'host' => 'hostname',
                    'port' => 1433,
                    'user' => 'user',
                    'password' => 'pass',
                    'dbname' => 'database',
                    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()
                )
            )
        )
    )
);

Now I've got no issues with MSSQL 2012
I hope my fix was correct

Comment by Steve Müller [ 05/Dec/14 ]

Patch provided: https://github.com/doctrine/dbal/pull/736

Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by man4red [ 05/Dec/14 ]

Dear friends,

I'm new here, and I don't know how all this works here, but can you help me?
As always when one bug fixed - another two produced

Now I've got another problem.
ZendDeveloperTool throws Exception

Uncaught exception 'PDOException' with message 'You cannot serialize or unserialize PDO instances'

of course because of my

    'platform' => new Doctrine\DBAL\Platforms\SQLServer2012Platform()

ok... my mistake

let's fix it in ZF2 way

    'platform' => 'Doctrine\DBAL\Platforms\SQLServer2012Platform'

Now we got another exception:

Doctrine\DBAL\DBALException: Invalid 'platform' option specified, need to give an instance of \Doctrine\DBAL\Platforms\AbstractPlatform.

let's look to doctrine\dbal\lib\Doctrine\DBAL\Connection.php Line: 387

    private function detectDatabasePlatform()
    {
        ...
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }
        ...
    }

So my question is

Can we implemet a feature and change this

    private function detectDatabasePlatform()
    {
        if ( ! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

to this (or similar)

    private function detectDatabasePlatform()
    {
        if (! isset($this->_params['platform'])) {
            $version = $this->getDatabasePlatformVersion();

            if (null !== $version) {
                $this->platform = $this->_driver->createDatabasePlatformForVersion($version);
            } else {
                $this->platform = $this->_driver->getDatabasePlatform();
            }
        } elseif ($this->_params['platform'] instanceof Platforms\AbstractPlatform) {
            $this->platform = $this->_params['platform'];
        } elseif (is_subclass_of($this->_params['platform'], 'Doctrine\DBAL\Platforms\AbstractPlatform')) {
            $this->platform = new $this->_params['platform']();
        } else {
            throw DBALException::invalidPlatformSpecified();
        }

        $this->platform->setEventManager($this->_eventManager);
    }

or this problem is only mine and I need to fix it by my self and to write some forks/mods etc?

Thx for your help anyway

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red that seems to be related with DBAL-1057 - I'll mark this issue as resolved.

Comment by man4red [ 05/Dec/14 ]

Marco Pivetta, thx! Is there planned some big reworking of this section, am I right?
Am I need to post my last comment to DBAL-1057 thread?

Comment by Marco Pivetta [ 05/Dec/14 ]

man4red this section needs some work for 2.5.1, yes. As for posting to DBAL-1057, please do, but only the bits that may be relevant and that you feel that add up to the discussion without cluttering it.





[DBAL-943] dbal db2 platform uses incorrect column modification strategy for clob Created: 20/Jul/14  Updated: 20/Jul/14

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

Type: Bug Priority: Critical
Reporter: chris rehfeld Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

db2 v10.5 centos 6.5



 Description   

db2 only allows certain column types to be used in an ALTER TABLE ALTER COLUMN myCol ... type statement.

Example entity

Widget2.php
<?php
/**
 * @ORM\Entity
 **/
class Widget
{
    /** @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue **/
    protected $id;

    /** @ORM\Column(type="string") **/
    private $str;
}

orm:schema-tool:create produces:
CREATE TABLE Widget2 (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, str VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id));

If you then change the column type from string to text via ...

Widget2.php
    /** @ORM\Column(type="text") **/
    private $str;

... and you then run orm:schema-tool:update, it will try to run:

ALTER TABLE WIDGET2 ALTER STR str CLOB(1M) NOT NULL;

The sql syntax is wrong, but that's a different issue I'll address elsewhere.Lets assume it's fixed to be proper syntax:
ALTER TABLE WIDGET2 ALTER COLUMN str SET DATA TYPE CLOB(1M) ALTER COLUMN str SET NOT NULL;

This triggers sql error code -190, sqlstate 42837
http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.codes/src/tpc/n190.dita

Because the from type => to type isn't valid. This link:
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.1.0/com.ibm.db2.udb.admin.doc/doc/r0000888.htm?lang=en
seems to list the valid alterations.

I'm guessing that a different strategy needs to be used; where we drop the old column, and create the new one in such scenarios. This could cause unexpected data loss though.






[DBAL-819] Schema-tools does not work on multiple Oracle's schemas Created: 21/Feb/14  Updated: 22/Feb/14

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

Type: Bug Priority: Major
Reporter: Antoine Descamps Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, oracle, orm, schematool
Environment:

DB: Oracle 11g



 Description   

The schema-tools, used via the CLI, is not able to detect schema's changes when working on multiple schemas.

For instance, the ORM is configured with a "global" Oracle's user, having permissions on every schemas. To specify which entities belong to which schema, I've prefixed the table name with the corresponding schema.

When trying to do the following command:

orm:schema-tool:update --dump-sql

Doctrine returns me the following message:

Nothing to update - your database is already in sync with the current entity metadata.

If, instead of using the "global" user in the Doctrine's configuration, I set the user of the specific schema I'm trying to generate a table on based from an entity, it works.



 Comments   
Comment by Steve Müller [ 21/Feb/14 ]

Moved this to DBAL for now. It seems to be related to schema prefixed table names not being evaluated in the platforms when generating the SQL for reverse engineering the database schema.

Comment by Steve Müller [ 22/Feb/14 ]

Antoine Descamps Okay after having investigated on this in detail and thinking about the possibilities we have to find a solution for this, I came to the following conclusion:
ORM's schema tool and DBAL's schema introspection are designed to be bound to what Doctrine defines as "database" for each platform. This is the scope of the whole operation. In case of Oracle it is the "user". You cannot break out of this scope in any way as the current DBAL implementation is not designed for a "complete" schema introspection and therefore does not allow it at some points. Fully understanding your concern I am afraid we cannot find a reasonable solution for your use case at this point in development (2.x). Furthermore there is a good reason for limiting the schema introspection to a certain layer. If the schema tool would introspect the "complete" schema without regard to the database it is connected to, it would suggest a lot of schema changes from other databases that do not belong to the context of the entity manager / database. This behaviour would even cause a lot more annoyance to users as it is the default use case that users are only interested in one database per entity manager.
Also this problem is completely independant from your mapping definitions. So it doesn't matter whether you prefix your table names or not. When running the "update" operation on the schema tool, it is the online schema introspection part that is preventing the schema tool from behaving as you would wish.
Changing the schema introspection behaviour in DBAL would completely break BC and is at some places in the code not even possible without changing the API.
I am sorry that I have to disappoint you with this conclusion but we I am afraid we cannot do anything about your issue until we start developing 3.x. We might reevaluate your use case their and see what we can do.





[DBAL-550] Complete/non-overridable event dispatching in DDL methods of AbstractPlatform Created: 22/Jun/13  Updated: 23/Dec/13

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

Type: Improvement Priority: Major
Reporter: Stéphane Klein Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: migrations, schematool


 Description   

The default implementation provided by the AbstractPlatform class dispatches several events related to schema modifications (create table, change column and so on) and offers the ability to prevent the default behaviour by setting a flag on the dispatched event. However, it appears that some DDL operations aren't covered by this mechanism (foreign keys creation, for example, doesn't seem to be observable). Furthermore, the concrete platforms can override any of these methods, potentially leading to inconsistancies in components that expect those events to be dispatched.

I'm working on a large modular application build on top of Symfony, in which each bundle must have its own migration classes (i.e. migrations on a per bundle basis, not at the application level), possibly with references to other parts of the schema. I used to write those classes manually using the dbal api, but this is tiedous and error-prone, and I'd like to take advantage of the mapping-based schema generation. I found that using the event system and "filtering" ddl operations to keep only the operations related to a given bundle is a clean and easy way to achieve this goal, but the issues I mentionned prevent me to complete the implementation.

I'd be glad to hear your opinion on that topic and, providing you're interested in it, contribute in a way or another to improve the existing code.



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

This is not a blocker

Comment by Benjamin Eberlei [ 22/Jun/13 ]

The DBAL event system is not in its best shape and definately could use some improvement. Your easiest way however would be to hook the process of generating the whole schema, and then dropping tables from those two to only contain the ones you are interested in.

Comment by Stéphane Klein [ 23/Jun/13 ]

That's indeed the simplest solution. Thanks a lot for your answer.

Comment by Steve Müller [ 23/Dec/13 ]

Benjamin Eberlei Is there anything to do here? Should the missing events be added or is that not necessary?





[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: 24/Dec/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


Issue Links:
Reference
is referenced by DBAL-96 Make approach towards identifier quot... Open

 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)



 Comments   
Comment by Steve Müller [ 24/Jun/13 ]

If those are reserved keywords, they should be added to the "PostgreSQLKeywords" class and they will be quoted by Doctrine. As far as I can see those keywords mentioned are not present in this class. Maybe there is something missing?





[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-40] Transparent table&column names escaping Created: 05/Aug/10  Updated: 26/Sep/13

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

Type: Improvement Priority: Major
Reporter: Jan Tichý Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 12
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.

Comment by Steve Müller [ 24/Jun/13 ]

Hello, if I understand correctly, the issue of quoting reserved keywords automatically is solved in https://github.com/doctrine/dbal/pull/302. Besides reserved keywords you can still decide quoting or not quoting identifier manually by passing quotes to the identifier or not.

Comment by Arthur Bodera [ 26/Sep/13 ]

It's still broken in 2.4.

PR 302 only selectively fixes indexes, PK and FK, but ALTER and all CRUD will still fail (and schema tool will produce invalid sql).

There is no performance hit, as all operations already hit `DefaultQuoteStrategy`.

Currently you have the following workarounds:

  • selectively add `quoted=true` to table and column names (ugh)
  • replace `DefaultQuoteStrategy` with strategy that quotes all identifiers.

Here is a class you can use: https://gist.github.com/Thinkscape/6713196

Comment by Arthur Bodera [ 26/Sep/13 ]

QuoteStrategies are not used for ALTER queries. This means that using the EagerQuoteStrategy mentioned above won't fix invalid ALTER queries generated by schema tool.

For ALTER to work, we need this merged:

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

Comment by Doctrine Bot [ 26/Sep/13 ]

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





[DBAL-642] Generated IDs are not guaranteed to be unique over the table's lifetime in SQLite Created: 27/Oct/13  Updated: 25/Jun/14

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

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


 Description   

In

http://docs.doctrine-project.org/en/2.0.x/reference/basic-mapping.html#identifier-generation-strategies

it says that MySQL and SQLite use AUTO_INCREMENT by default. The generated SQL for creating an ID field with GENERATOR_TYPE_AUTO looks like this (abbreviated
for readability):

CREATE_TABLE_TEST (id INTEGER DEFAULT 0 NOT NULL, PRIMARY KEY(id))

http://www.sqlite.org/faq.html#q1 states:

If you declare a column of a table to be INTEGER PRIMARY KEY, then whenever you insert a NULL into that column of the table, the NULL is automatically converted into an integer which is one greater than the largest value of that column over all other rows in the table, or 1 if the table is empty. [...] Note that the integer key is one greater than the largest key that was in the table just prior to the insert. The new key will be unique over all keys currently in the table, but it might overlap with keys that have been previously deleted from the table.

So in other words, if you remove an entity and then create a new one, the new one will have the same id as the previously deleted one. If you do both operations on the same entitymanager, id references (in proxies f.x.) will suddenly get confused and point to something else (at least that's my current theory..)

The point is: SQLite doesn't act like MySQL as the documentation implies, and IMHO SQLite's current behaviour makes it useless for more complex scenarios. I've found some reference to this problem here:

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

Unfortunately, it doesn't mention any solution. The problem is that you can't override the columnDefinition, because it would have to be "INTEGER PRIMARY KEY AUTOINCREMENT", but then, you get an exception, because the Platform appends ", PRIMARY KEY(id)", so it's defined twice



 Comments   
Comment by Steve Müller [ 25/Nov/13 ]

As far as I understand there is a conflict in SQLite between having an autoincrement primary key and having a composite primary because you can only choose either way. The PR you referenced removed the autoincrement behaviour in favour of having the opportunity to define composite primary keys. So what would you expect to be the solution here?

Comment by flack [ 25/Nov/13 ]

Well, from a user's point of view, it would be nice if the SQLite Platform implementation would make full use of the possibilities of SQLite. That is to say: If someone uses composite primary, they get the behaviour Doctrine has right now, and those that use the simple case (which is recommended all over the documentation), get the behaviour previous to the pull request, i.e. autoincrement that works like in MySQL (which the documentation implies). As far as I understood the discussion in the pull request, the author was looking for a solution to implement this, but then the PR was merged before the issue was solved.

Comment by flack [ 25/Nov/13 ]

I guess what is bothering me is that the current behaviour breaks assumptions that I think many applications using Doctrine make. At least I know that in my own code, I never planned for the possibility of a database primary key being re-used for a different object, especially not during the same request. And like I wrote above, I suspect that Doctrine itself is not totally prepared for that situation either (also mentioned here: https://github.com/doctrine/dbal/pull/66#discussion_r173623). So IMHO the IDENTIY generator strategy for SQLite seems broken, or at least is behaving unexpectedly. The documentation says

AUTO (default): Tells Doctrine to pick the strategy that is preferred by the used database platform. The preferred strategies are IDENTITY for MySQL, SQLite and MsSQL and SEQUENCE for Oracle and PostgreSQL. This strategy provides full portability.

I don't really see how the current behaviour can be said to provide full portability (at least with MySQL, which supposedly uses the same preferred strategy)

Comment by Steve Müller [ 25/Nov/13 ]

Yeah I get your point. But it's always hard and error prone to work around the vendors lack of common features. A possibility COULD be to implement a trigger in columns declared as autoincrement which simulates the behaviour of an auotincrement column on inserts. Oracle uses a similar workaround with a trigger and a sequence to simulate autoincrement columns. But this is just an idea and has to evaluated for usability first.

Comment by Steve Müller [ 25/Nov/13 ]

Yes that's true. The documentation is misleading here. I guess that it was written before the issue came up and then was not updated. Unfortunately SQLite does not support native sequences which would make life a lot easier. But I will keep that in mind and investigate a solution for this.

Comment by Benjamin Eberlei [ 13/Dec/13 ]

I think there is no fix for this, this is just how SQLite works, and we cannot really keep the last ids somewhere. IMHO its a documentation issue.

Comment by flack [ 13/Dec/13 ]

Well, you cannot fix it for cases with multiple id columns (but the Doctrine documentation already suggests that they should be avoided where possible), but for single integer columns (which is the normal case, as suggested by documentation), SQLite provides all the necessary functionality, as long as you create the column with INTEGER PRIMARY KEY AUTOINCREMENT. So IMHO the best solution would be if support for this could be implemented somehow in the SQL Platform driver.

Comment by flack [ 14/Dec/13 ]

Case in point: I implemented exactly this in a Doctrine adapter I'm working on:

https://github.com/flack/midgard-portable/blob/master/src/midgard/portable/storage/subscriber.php#L136

Granted, this is a very ugly workaround that only works because I know all my ID columns are actually called 'id' (and will never change), but I'm fairly sure that a more general solution could be built with reasonable effort.

Comment by Benjamin Eberlei [ 01/Jan/14 ]

flack We removed the Sqlite AUTOINCREMENT for some weird reason. I am inclined to add this again, however I need to find out what the reasons for removing this have been.

Comment by Steve Müller [ 01/Jan/14 ]

Benjamin Eberlei I checked that lately and I came to the same conclusion. The reason why it was removed is to support composite primary keys which was not possible before somehow. We could add autoincrement if only a single column integer primary key is given I think...

Comment by flack [ 25/Jun/14 ]

Just noticed that the link I posted above is broken now. Here's a stable one:

https://github.com/flack/midgard-portable/blob/04d473356d804c7f64e940ef82dd1538c39fccdd/src/storage/subscriber.php#L170

The workaround is a bit less project-specific now, and might serve as the basis for a real solution I guess (basically, only checks for column type and composite keys would need to be added)





[DBAL-939] schema update doesnt detect boolean type correctly Created: 16/Jul/14  Updated: 20/Jul/14

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

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

centos 6 64, db2 luw10.5



 Description   

*edited*

Dbal for db2 doesn't seem to be able to differentiate between a smallint and a boolean field on db2. If I make an entity which has a boolean field, it will create a table using type smallint. If I later try to update the schema, it will detect the column in the table as a small int, not a boolean. So, it will produce sql update statements to change the type from smallint to smallint, which is obviously unnecessary. I understand db2 doesn't have a boolean type, but it would be nice if dbal realized that a smallint is essentially already a dbal boolean.

Additionally, the update statement is invalid syntax and fails, although this is probably a separate issue.

Example entity

Widget.php
<?php
/**
 * @ORM\Entity
 **/
class Widget
{
    /** @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue **/
    protected $id;

    /** @ORM\Column(type="boolean", nullable=false) **/
    private $isGoat;
}

orm:schema-tool:create produces:
CREATE TABLE Widget (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, isGoat SMALLINT NOT NULL, PRIMARY KEY(id));

If you then run orm:schema-tool:update, it will try to run:

ALTER TABLE WIDGET ALTER ISGOAT isGoat SMALLINT NOT NULL; CALL SYSPROC.ADMIN_CMD ('REORG TABLE WIDGET');

but no column alteration is obviosuly needed.

So in summary, smallint to boolean type mapping isn't realized, causing the update command to think it needs to change the type of the column.






[DBAL-970] Implement partial indexes for missing platforms Created: 12/Aug/14  Updated: 12/Aug/14

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

Type: Improvement Priority: Major
Reporter: Steve Müller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

As a follow-up to DBAL-900 there are some platforms left that support partial indexes too and need the implementation for that feature.
Currently partial indexes are only implemented for PostgreSQL.
Additionally there should be a functional test covering creation and introspection of partial indexes if possible.






[DBAL-999] Get a Sql Server error on Order By - Symfony2 Created: 08/Oct/14  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Maël SOURISSEAU Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orderBy, query, sqlserver


 Description   

Using Symfony with Sql Server and from what I've read, it seems that the connection to the database is not stable.

As soon as I use the orderBy method I get an error :

Here's an example :

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
  $qStores =
        $this->getManager()
             ->createQueryBuilder()
             ->select('rpdv')
             ->from('MainBundle:PointDeVenteReference', 'rpdv')
             ->andWhere( 'rpdv.partenaireClient = :id_partner ' )
                 ->setParameter( 'id_partner', $this->getUser()->getPartenaire()->getIdPartenaire() )
             ->orderBy( 'rpdv.idPointDeVenteReference' , 'DESC' )
             ->setFirstResult( 0 )
             ->setMaxResults( 30 );

And the error :

An exception has been thrown during the rendering of a template ("An exception occurred while executing
'SELECT DISTINCT TOP 30 id_point_de_vente_reference0
FROM ( SELECT p0_.id_point_de_vente_reference AS id_point_de_vente_reference0,
p0_.reference AS reference1,
p0_.date_derniere_modification AS date_derniere_modification2,
p0_.blocage AS blocage3
FROM point_de_vente_reference p0_
WHERE p0_.id_partenaire_client = ?
ORDER BY p0_.id_point_de_vente_reference DESC ) dctrn_result
ORDER BY id_point_de_vente_reference0 DESC'
with params [2829]:SQLSTATE[42000]:
[Microsoft][SQL Server Native Client 11.0][SQL Server]
The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions,
unless TOP, OFFSET or FOR XML is also specified.") in MainBundle:Default:store/list.html.twig at line 79.
I tried to change the class SQLServerPlatform with corrections found on the net, without success.

Do you have any idea?

Thx !



 Comments   
Comment by Steve Müller [ 08/Oct/14 ]

Which version of DBAL are you using? A lot of fixes have been applied to SQL Server's LIMIT/OFFSET query rewriting in DBAL during the last months.

Comment by Maël SOURISSEAU [ 08/Oct/14 ]

2.4 for DBAL.

Under my request, I have :

$stores = new Paginator( $qStores, TRUE );

In passing the second parameter to FALSE, I have no error.

Comment by Marco Pivetta [ 19/Oct/14 ]

I'd suggest checking ORM+DBAL latest to see if the issue still exists, as those component have suffered from radical changes in the last few months.





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

Status: In Progress
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.3.2
Fix Version/s: 2.6
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?

Comment by Steve Müller [ 03/Jan/14 ]

Max Milaney Can you please test if this still exists in the current master branch? If so, can you please provide the information requested by Benjamin Eberlei ? Otherwise hunting this down is rather hard... Thank you!





[DBAL-96] Make approach towards identifier quoting consistent Created: 26/Feb/11  Updated: 04/Dec/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
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
relates to DBAL-477 Just doublequote all schema names and... Open
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



 Comments   
Comment by Steve Müller [ 24/Dec/13 ]

Benjamin Eberlei this is an interesting approach and I like it. But I have some complaints about it.
1. I doubt users will be happy about forced default casing rules (ALL upper or ALL lower). Therefore we should think about adding a simple configuration option in DBAL allowing to override the default casing behaviour to the user's preference.
2. Using a consistent default casing means we ALWAYS have to quote identifiers as otherwise the underlying database could silently change the case again (don't know if this is an issue).
3. Introducing this approach in 2.x branch is a BC break as it breaks users' mixed-case identifier mappings.

For 2.x we should maybe at least make use of Identifier class throughout the platforms where necessary.





[DBAL-1060] [GH-736] [DBAL-1058] Fix database and namespace introspection for SQL Server Created: 05/Dec/14  Updated: 05/Dec/14

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

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

Issue Links:
Reference
relates to DBAL-1058 It seems that MSSQL syntax was changed Open
is referenced by DBAL-1061 [GH-737] [DBAL-1058] [2.4] Fix databa... Open

 Description   

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

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

Message:

It looks like some SQL Server versions / setups need system tables to be queried lowercased otherwise causing errors.



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DBAL-1061] [GH-737] [DBAL-1058] [2.4] Fix database names introspection for SQL Server Created: 05/Dec/14  Updated: 05/Dec/14

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

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

Issue Links:
Reference
relates to DBAL-1058 It seems that MSSQL syntax was changed Open
relates to DBAL-1060 [GH-736] [DBAL-1058] Fix database and... Open

 Description   

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

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

Message:

Backport of #736 to 2.4 branch.



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DBAL-1069] datetimetz type needs to be a commented one by default Created: 10/Dec/14  Updated: 10/Dec/14

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

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


 Description   

By default, the AbstractPlatform creates datetimetz fields as datetime field for platforms not defining a specific creation for fields with timezones.
This can be an acceptable fallback if you know that your application always send the value as UTC even when the database can accept any timezone as input thanks to the datetimetz type (database not supporting timezone would still have consistent data if you always send the same timezone).
However it creates an issue for the SchemaTool: the field will obviously be reported as datetime when inspecting the DB, not as datetimetz (since it does not have a datetimetz). So for platforms not supporting datetimetz natively, the special comment should be used to avoid useless updates.
The special Doctrine command should however not be used for platforms supporting the type natively (PostgreSQL, SQLServer2008, Oracle and SqlAnywhere12).

I have an idea about a fix, so I may send a PR for this in the following days.






[DBAL-1070] AzureSQL specificities are not taken into account Created: 11/Dec/14  Updated: 11/Dec/14

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

Type: Bug Priority: Major
Reporter: Nicolas Séverin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: azure, dbal, sqlserver
Environment:

Azure website using an AzureSQL database (based on SQL Server 2012).



 Description   

In Azure SQL, table ‘sys.extended_properties’ does not exist.
But SQLAzurePlatform inherits from class SQLServerPlatform, which uses it.
The code in question is here /Doctrine/DBAL/Platforms/SQLServerPlatform.php#L845.

Modifications to this portion of code were made to handle comments on columns differently in doctrine/dbal 2.5, but it used to work in 2.4.3.



 Comments   
Comment by Marco Pivetta [ 11/Dec/14 ]

Reverted to priority Major





[DBAL-1077] Query limit for sql server Created: 16/Dec/14  Updated: 16/Dec/14

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

Type: Bug Priority: Major
Reporter: yannick LE LAN Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, regex, sqlserver
Environment:

sql server



 Description   

On branch master: tests/Doctrine/Tests/DBAL/platforms/AbstractSQLServerPlatformTestCase.php
On branch 2.4: tests/Doctrine/Tests/DBAL/platforms/SqlServerPlatformTest.php

public function testModifyLimitQueryFolcoerr()
{

    $sql = $this->_platform->modifyLimitQuery('SELECT son.label AS Name FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0 ORDER BY son.identifier DESC', 1, 0);

    $this->assertEquals('SELECT * FROM (SELECT son.label AS Name, ROW_NUMBER() OVER (ORDER BY son.identifier DESC) AS doctrine_rownum FROM SqlObjectName son WHERE ( SELECT COUNT(eso.identifier) FROM ExtractedSqlObject eso INNER JOIN ProductionDbName pdn ON eso.ref_ProductionDbName_ID = pdn.identifier AND (pdn.label IN (?, ?)) WHERE eso.ref_SqlObjectName_ID = son.identifier) > 0) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 1 ORDER BY doctrine_rownum', $sql);

}

Correction proposed:
on both branches: lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php

protected function doModifyLimitQuery(...)
{
    ...

    #ACTUAL: 
    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/i';

#CORRECT:

    $selectFromPattern = '/^(\s*SELECT\s+(?:(.*)(?![^(]*\))))\sFROM\s/iU';

explanation: "/U" pattern modifier => http://php.net/manual/en/reference.pcre.pattern.modifiers.php
Ungreedy behavior not susceptible to fall on ?! negative lookahead on parenthesis hunger

  1. has impacts on ORM with setMaxResults (which was failing in my case and made me investigate)


 Comments   
Comment by Marco Pivetta [ 16/Dec/14 ]

Can you send a PR for this change instead?

Comment by yannick LE LAN [ 16/Dec/14 ]

I will do so by the end of the week,





[DBAL-422] Wrong VARCHAR default length in SQLServerPlatform Created: 24/Jan/13  Updated: 27/Dec/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.



 Comments   
Comment by Steve Müller [ 27/Dec/13 ]

The implementation is inconsistent on other platforms, too and can first be addressed in 3.0 I think. Otherwise this would be a BC break.





[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: 1
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-1048] Function based index Created: 20/Nov/14  Updated: 20/Nov/14

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

Type: New Feature Priority: Minor
Reporter: Grégoire Paris Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql


 Description   

I would like to create a function-based index, but it does not seem to be possible ATM. The final goal is to be able to have case insensitive string filters with Postgresql without losing performance.

I tried this mapping :

  indexes:
        my_entity_name_index:
            columns: [ LOWER(name) ]

But here is what doctrine answers :

[Doctrine\DBAL\Schema\SchemaException]

There is no column with name 'LOWER(name)' on table 'my_entity'.



 Comments   
Comment by Marco Pivetta [ 20/Nov/14 ]

I don't think that we can provide platform-specific index column name support here.





[DBAL-1082] SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 18/Dec/14

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

Type: Bug Priority: Minor
Reporter: Daniel Chesterton Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, schematool
Environment:

MySQL



 Description   

The schema update tool does not consider the possibility that MySQL double/float fields can be unsigned.

When running the CLI tool, it recognises that the schemas differ but it doesn't add the appropriate 'UNSIGNED' SQL statement. For example when the database is SIGNED but the entity is marked as UNSIGNED, running the tool with --dump-sql will generate SQL similar to below:

ALTER TABLE tablename CHANGE field field DOUBLE PRECISION NOT NULL;

Running this has no effect on the database and subsequent calls will try to run the same SQL.

I have created a pull request in GitHub which fixes the issue.






[DBAL-1020] Postgres and using Schema tool throws cardinality errors Created: 22/Oct/14  Updated: 23/Oct/14

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

Type: Bug Priority: Critical
Reporter: Dominic Watson Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: ddl, postgresql

Attachments: PNG File 6ZeW_jJFUbOCx5uGJ2feANtAsZOr72zhDL4szJ6p5VE.png     File pg_catalog_pg_class.csv    

 Description   

Postgres: 9.3.5.0 (Postgres App for OSX) w/ PostGIS extensions
doctrine/common: 2.4.x-dev ae92d076442e27b6910dd86a1292a8867cf5cfe4
doctrine/dbal: dev-master 1c9c24a7e2295b71249ae2a719ce38861fccd551
creof/doctrine2-spatial: https://github.com/intellix/doctrine2-spatial 4023ca8fbe703043012c31d6df26b9bc7b0a972d

It seems every now and again when I come to use the schema-tool I'm getting exceptions which can only be fixed by dropping the database and recreating from scratch.

The following SQL looks to be generated here: \Doctrine\DBAL\Platforms\AbstractPlatform::getListTableForeignKeysSQL

SELECT quote_ident(r.conname) as conname, pg_catalog.pg_get_constraintdef(r.oid, true) as condef
                  FROM pg_catalog.pg_constraint r
                  WHERE r.conrelid =
                  (
                      SELECT c.oid
                      FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n
                      WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"',user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace
                  )
                  AND r.contype = 'f'

The full stack trace is as follows:

 ---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~--
  Dropping database schema...
      ./bin/doctrine-module orm:schema-tool:drop --force --verbose
---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~---~--
Dropping database schema...


                                                                                                                                                                                                       
  [Doctrine\DBAL\Exception\DriverException]                                                                                                                                                            
  An exception occurred while executing 'SELECT quote_ident(r.conname) as conname, pg_catalog.pg_get_constraintdef(r.oid, true) as condef                                                              
                    FROM pg_catalog.pg_constraint r                                                                                                                                                    
                    WHERE r.conrelid =                                                                                                                                                                 
                    (                                                                                                                                                                                  
                        SELECT c.oid                                                                                                                                                                   
                        FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n                                                                                                                          
                        WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"'  
  ,user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace                                                                                              
                    )                                                                                                                                                                                  
                    AND r.contype = 'f'':                                                                                                                                                              
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression                                                                                     
                                                                                                                                                                                                       


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractPostgreSQLDriver.php:82
 Doctrine\DBAL\Driver\AbstractPostgreSQLDriver->convertException() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:116
 Doctrine\DBAL\DBALException::driverExceptionDuringQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:833
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4




                                                                                                                    
  [Doctrine\DBAL\Driver\PDOException]                                                                               
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression  
                                                                                                                    


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:94
 Doctrine\DBAL\Driver\PDOConnection->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:830
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4




                                                                                                                    
  [PDOException]                                                                                                    
  SQLSTATE[21000]: Cardinality violation: 7 ERROR:  more than one row returned by a subquery used as an expression  
                                                                                                                    


Exception trace:
 () at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:92
 PDO->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:92
 Doctrine\DBAL\Driver\PDOConnection->query() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:830
 Doctrine\DBAL\Connection->executeQuery() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:761
 Doctrine\DBAL\Connection->fetchAll() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:319
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableForeignKeys() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:284
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTableDetails() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:268
 Doctrine\DBAL\Schema\AbstractSchemaManager->listTables() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php:1039
 Doctrine\DBAL\Schema\AbstractSchemaManager->createSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:783
 Doctrine\ORM\Tools\SchemaTool->getDropSchemaSQL() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/SchemaTool.php:727
 Doctrine\ORM\Tools\SchemaTool->dropSchema() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:100
 Doctrine\ORM\Tools\Console\Command\SchemaTool\DropCommand->executeSchemaCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/AbstractCommand.php:65
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:891
 Symfony\Component\Console\Application->doRunCommand() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at /Users/dominicwatson/Sites/flatscanner/api/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module.php:58
 include() at /Users/dominicwatson/Sites/flatscanner/api/bin/doctrine-module:4


orm:schema-tool:drop [--dump-sql] [-f|--force] [--full-database]


 Comments   
Comment by Marco Pivetta [ 22/Oct/14 ]

What are the contents of pg_catalog.pg_class ?

Comment by Dominic Watson [ 22/Oct/14 ]

Uploaded CSV of that table

Comment by Dominic Watson [ 22/Oct/14 ]

After running the subquery as suggested in IRC:

  SELECT c.oid                                                                                                                                                                   
                        FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n                                                                                                                          
                        WHERE n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND c.relname = 'state' AND n.nspname = ANY(string_to_array((select replace(replace(setting,'"$user"'  
  ,user),' ','') from pg_catalog.pg_settings where name = 'search_path'),',')) AND n.oid = c.relnamespace  

oid
-------
40152
39687

Comment by Marco Pivetta [ 22/Oct/14 ]

Can you run the query:

SELECT
    c.*
FROM
   pg_catalog.pg_class c, pg_catalog.pg_namespace n
WHERE
    n.nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast')
    AND c.relname = 'state'
    AND n.nspname = ANY(string_to_array((
        select replace(replace(setting,'"$user"', user), ' ', '')
        from pg_catalog.pg_settings
        where name = 'search_path'
    ),','))
    AND n.oid = c.relnamespace
Comment by Dominic Watson [ 22/Oct/14 ]
  relname varchar,
  relnamespace oid,
  reltype oid,
  reloftype oid,
  relowner oid,
  relam oid,
  relfilenode oid,
  reltablespace oid,
  relpages int,
  reltuples real,
  relallvisible int,
  reltoastrelid oid,
  reltoastidxid oid,
  relhasindex bool,
  relisshared bool,
  relpersistence char(1),
  relkind char(1),
  relnatts smallint,
  relchecks smallint,
  relhasoids bool,
  relhaspkey bool,
  relhasrules bool,
  relhastriggers bool,
  relhassubclass bool,
  relispopulated bool,
  relfrozenxid xid,
  relminmxid xid,
  relacl _aclitem,
  reloptions _text

state,2200,40154,0,10,0,40152,0,0,0,0,0,0,true,false,p,r,2,0,false,true,false,true,false,true,6694,1,NULL,NULL
state,39587,39689,0,10,0,39687,0,0,0,0,39694,0,true,false,p,r,15,3,false,true,false,false,false,true,6629,1,NULL,NULL
Comment by Dominic Watson [ 22/Oct/14 ]

My ZF2 onBootstrap as well, in case it changes anything:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
<?php
namespace Flatscanner;

use Doctrine\ORM\Mapping\UnderscoreNamingStrategy;
use ZF\Apigility\Provider\ApigilityProviderInterface;
use Zend\Uri\UriFactory;
use Doctrine\DBAL\Types\Type;

class Module implements ApigilityProviderInterface
{
    public function getConfig()
    {
        return include __DIR__ . '/../../config/module.config.php';
    }

    public function onBootstrap($e)
    {
        Type::addType('geometry', 'CrEOF\Spatial\DBAL\Types\GeometryType');
        Type::addType('point', 'CrEOF\Spatial\DBAL\Types\Geometry\PointType');
        UriFactory::registerScheme('chrome-extension', 'Zend\Uri\Uri');

        // Set naming strategy
        $em = $e->getTarget()->getServiceManager()->get('doctrine.entitymanager.orm_default');
        $em->getConnection()->getDatabasePlatform()->registerDoctrineTypeMapping("_text", "text"); // assuming it is a text LOB
        $em->getConfiguration()->setNamingStrategy(new UnderscoreNamingStrategy(CASE_LOWER));
    }

    public function getAutoloaderConfig()
    {
        return array(
            'ZF\Apigility\Autoloader' => array(
                'namespaces' => array(
                    __NAMESPACE__ => __DIR__,
                ),
            ),
        );
    }
}
Comment by Steve Müller [ 23/Oct/14 ]

Most probably also affects 2.4 as the codebase has not changed at the critical places. Possibly 2.3 is also affected by this. Could need a check.





[DBAL-235] Column order is not synchronized by Comparator Created: 08/Mar/12  Updated: 19/Dec/13

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!

Comment by Steve Müller [ 18/Dec/13 ]

AFAIK only MySQL supports changing column order after table creation. All other vendors need a table recreation for this. Why exactly do you need this? I cannot think of a use case where the order in which columns are stored in the table is of any importance. And as this is a MySQL only specific feature which needs some heavy calculations in the comparator, I doubt this will be implemented...

Comment by Artem Goutsoul [ 19/Dec/13 ]

It's very convenient to use MySQL column order so that the columns show up in some sane order in DB management tools.
Also an application can show some tables in a sane way without explicit column order specification.

We are currently using it widely in our app. Our ORM is actually picking up the object specifications directly from the database and it's not specified in the application code.

Comment by Steve Müller [ 19/Dec/13 ]

Artem Goutsoul I get the point. But as I already stated only MySQL supports column reordering without requiring a table recreation AFAIK. How would you expect other platforms to behave in column reordering scenarios? I think it's weird if only MySQL platform can react to column reorderings and we have to adjust the comparator for a just a single platform. Benjamin Eberlei what would you say?





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

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.



 Comments   
Comment by Steve Müller [ 24/Jun/13 ]

May this be an issue fixed by https://github.com/doctrine/dbal/pull/302 ?





[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: 2
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-474] SchemaManager / Connection on PostgreSQL platform does not respect filterExpression for sequences Created: 27/Mar/13  Updated: 16/May/14

Status: In Progress
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: Steve Müller
Resolution: Unresolved Votes: 1
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.

Comment by Steve Müller [ 06/Jan/14 ]

jos de witte I think your issue got fixed in commit: https://github.com/doctrine/dbal/commit/8beb732fe9d5cd40a0d677f250d2be325482744f
This patch was first introduced in 2.3. Can you please confirm that this is fixed? Otherwise can you please provide a concrete example so that we can reproduce you issue?

Comment by Arnout Standaert [ 29/Jan/14 ]

I believe we are bumping into the same issue. Our webapp uses Migrations, but for our webapp we are limited to a certain schema within a bigger PostgreSQL database. We only have permissions on our own schema and public.
Now, listSequences in AbstractSchemaManager does filter the asset names correctly with the mentioned fix.

But the problem is with the step before, _getPortableSequencesList (see line 135 of AbstractSchemaManager):

        return $this->filterAssetNames($this->_getPortableSequencesList($sequences));

This function goes out and does a _getPortableSequenceDefinition on every sequence in the unfiltered list. For every sequence, the _getPortableSequenceDefinition in PostgreSqlSchemaManager performs a SELECT:

        $data = $this->_conn->fetchAll('SELECT min_value, increment_by FROM ' . $this->_platform->quoteIdentifier($sequenceName));

Now, our user role in the database doesn't have SELECT permissions on these sequences in other schemas, so the migration fails with a privilege error.

There should be some kind of filtering on the sequence list BEFORE the SELECT statement in the _getPortableSequenceDefinition function are performed, no?

Comment by Arnout Standaert [ 30/Jan/14 ]

I currently have a workaround running locally, which filters the sequences list before creating the PortableSequence's. This is probably hackish and a poor workaround, just posting here as a temporary solution and further illustration of the problem.

Altered line 135 in AbstractSchemaManager:

        return $this->_getPortableSequencesList($this->filterSequenceNames($sequences));

I added function filterSequenceNames() in AbstractSchemaManager for appropriate sequence filtering:

    /**
     * Filters sequence names if they are configured to return only a subset of all
     * the found elements.
     *5
     * @param array $sequenceNames
     *
     * @return array
     */
    protected function filterSequenceNames($sequenceNames)
    {
        $filterExpr = $this->getFilterSchemaAssetsExpression();
        if ( ! $filterExpr) {
            return $sequenceNames;
        }
        
        return array_values ( array_filter($sequences, function ($sequenceName) use ($filterExpr) {
                $sequenceName = $sequenceName["schemaname"].".".$sequenceName["relname"];
                return preg_match($filterExpr, $sequenceName);
            })
        );

    }

After these modifications, doctrine:migrations:migrate operations complete succesfully, even with our limited-permission database account.

Comment by Steve Müller [ 21/Feb/14 ]

Arnout Standaert Your fix looks promising and reasonable. Can you create a PR on the DBAL repo for that?

Comment by Viktor Sidochenko [ 15/Mar/14 ]

Why this fix is not in master?

Comment by Steve Müller [ 15/Mar/14 ]

Viktor Sidochenko because nobody has fixed it yet Feel free to provide a patch on GitHub.

Comment by Arnout Standaert [ 17/Mar/14 ]

I haven't gotten around to doing the PR on GitHub yet, I'm not yet too familiar with that.
I'll try to find some time for this the coming days.

Comment by Viktor Sidochenko [ 17/Mar/14 ]

Will be good. I`m not professional developer to make patches to upstream. So just voted for this issue.

Comment by Steve Müller [ 19/Mar/14 ]

Patch supplied in PR: https://github.com/doctrine/dbal/pull/546
jos de witte, Arnout Standaert, Viktor Sidochenko can you please test if the supplied PR fixes the problem?

Comment by Doctrine Bot [ 16/May/14 ]

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





[DBAL-916] Some alter table statements do not respect @Table name value Created: 30/May/14  Updated: 04/Jun/14

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

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

MacOS



 Description   

I have specified the table name for each class generating a table. I find that some table names are respected during doctrine update upon the database, and some are not.

Specifically it seems that simpler entities, one's annotated with entity/table become lower case, while more complicated ones (inheritance map) respect the given table name.



 Comments   
Comment by Julia Smith [ 03/Jun/14 ]

On further inspection, this does not appear to be a bug with Doctrine. A simple dump of the update statements generated shows no table name change, but:

ALTER TABLE Comment DROP FOREIGN KEY FK_5BC96BF03DBEAF48;
DROP INDEX IDX_5BC96BF03DBEAF48 ON Comment;
ALTER TABLE Comment CHANGE replyto_id replytox_id INT DEFAULT NULL;
ALTER TABLE Comment ADD CONSTRAINT FK_5BC96BF0484A4D29 FOREIGN KEY (replytox_id) REFERENCES Comment (id);
CREATE INDEX IDX_5BC96BF0484A4D29 ON Comment (replytox_id);

Somehow causes mysql to change the case of the table on MacOS.

weird.

Comment by Steve Müller [ 04/Jun/14 ]

Julia Smith can you please provide more details concerning your actual problem? I'm not sure I understand what the problem is here. I can't see how the SQL you pointed out changes a table's name in any way so I don't understand how that could change the table name's case.
Concerning identifier casing in general I would suggest you to read the following from the MySQL documentation:
http://dev.mysql.com/doc/refman/5.5/en/identifier-case-sensitivity.html

And a pretty good explanation of the problem with identifiers and case accross operating systems and database vendors:
http://www.alberton.info/dbms_identifiers_and_case_sensitivity.html#.U47DV3IZWlM

If the casing of identifiers (table names, column names etc.) in your schema is important for you, you will either have to quote those in your mapping explicitly or use a custom quoting strategy. Please refer to the documentation for further details:
http://docs.doctrine-project.org/en/latest/reference/basic-mapping.html#quoting-reserved-words

Hope that helps.





[DBAL-936] Doctrine type not found exception thrown before checking the comment Created: 10/Jul/14  Updated: 11/Jul/14

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

Type: Bug Priority: Major
Reporter: Maxime Veber Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, mysql


 Description   

Here is the piece of code:

$type = $this->_platform->getDoctrineTypeMapping($dbType);

// In cases where not connected to a database DESCRIBE $table does not return 'Comment'
if (isset($tableColumn['comment'])) {
    $type = $this->extractDoctrineTypeFromComment($tableColumn['comment'], $type);
    $tableColumn['comment'] = $this->removeDoctrineTypeFromComment($tableColumn['comment'], $type);
}

The method `getDoctrineTypeMapping` throw an exception if the type is not found. But for example if you have an enum type (see the doctrine cookbook on the subject), the type is setted as comment.

Doctrine throw the exception before having the occasion to get the type via comment.

Here are two solutions:

  • Check for comment before throw the exception
  • Adding the enum type to the doctrine platform and mapping it to string





[DBAL-1017] Altering a foreign key column is not done properly for MySQL Created: 21/Oct/14  Updated: 21/Oct/14

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, schematool


 Description   

Altering a foreign key column column (for instance to make it not-nullable) or the index of a foreign key does not work on MySQL (to be exact, it does not work on some MySQL setups, but I haven't found the config setting impacting it yet). Making it work requires dropping the foreign key before altering the column/index and readding it after



 Comments   
Comment by Steve Müller [ 21/Oct/14 ]

Christophe Coevoet DBAL-732 related?





[DBAL-1085] Custom Type Compare Fails To Generate Correct Migrations Created: 19/Dec/14  Updated: 19/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0, 2.1, 2.2, 2.3, 2.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nicolas Vanheuverzwijn Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: migrations
Environment:

Everywhere



 Description   

// From doctrine 2.1
public function diffColumn(Column $column1, Column $column2)
{
$changedProperties = array();
if ( $column1->getType() != $column2->getType() )

{ $changedProperties[] = 'type'; }

...
}
The $column1->getType() will return the underlying platform object but the $column2->getType() will return the custom object type.

Because of the way the php compare function works, a custom type will always generate a changed property over the type of a column.

http://stackoverflow.com/questions/26964367/symfony2-doctrine-custom-types-generating-unneeded-migrations/27557785#27557785






[DBAL-812] SchemaTool ignores multi-columns (composite) indexes when creating a foreign key Created: 13/Feb/14  Updated: 15/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Peter Huynh Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

MySQL



 Description   

When using the schema tool to generate the differences between the db and the entities, I notice the following:

ALTER TABLE sales ADD CONSTRAINT FK_36D222EF603EE73 FOREIGN KEY (vid) REFERENCES vendor (id);
CREATE INDEX IDX_36D222EF603EE73 ON sales (vid);

Normally, it doesn't bother me, however I have had an existing composite index consists of (vid, submit). This leads to the redundant index IDX_36D222EF603EE73 and therefore forcing unnecessary overheads.

It would be nice to have a mean to disable this from happening.

The code in question can be found at https://github.com/doctrine/dbal/blob/594e326bd58d1d7af578f0dc3143655b9d119d45/lib/Doctrine/DBAL/Schema/Table.php#L543.

A helpful member from #doctrine IRC also pointed out that it does not check the unique constraints also.

Regards,



 Comments   
Comment by Marco Pivetta [ 13/Feb/14 ]

Just a hint on this: looks like the current logic just checks hashed indexes, ignoring the "uniq" prefixed indexes to avoid duplicates.

Comment by Steve Müller [ 15/Feb/14 ]

Peter Huynh I get the point here. However after having a quick look into this it seems this behaviour exists for a good reason. See here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Index.php#L191-L195
The question is how could this reasonable extended to fulfil the needs you explained. I am not entirely sure about this and this peace of code is rather sensitive and critical. I don't want to rush any assumptions here.

Comment by Peter Huynh [ 15/Feb/14 ]

Hi Steve,

I fully understand your reservation.

Thanks for looking into things.

Peter





[DBAL-598] Schema Comparator is case insensitive for table names Created: 05/Sep/13  Updated: 07/Oct/13

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: Justin Martin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Comparator.php#L102

The schema comparator currently uses strtolower for all table name comparison, so differences in case will not be detected.

When updating a schema using the schema tool, the tool will not perform any modification if the case of a table name has changed.

An example of this case would be when one is writing entities for the ORM, and the naming includes uppercase letters. You generate your schema and it uses the equivalent case for the initial generation. Then, you write Table annotations to change the name of the tables to lowercase. The schema comparator would not detect this, and depending upon the case sensitivity of the SQL engine, this could result in SQL errors.



 Comments   
Comment by Jeremiah Small [ 07/Oct/13 ]

This is the closest existing issue I could find to a problem we are having with the schema tool update and case insensitivity. If this is a separate bug, I'd be happy to write it up, but I don't have create privs in Jira yet.

Here's the bug:

If we add a new association, and do php vendor/bin/doctrine-module orm:schema-tool:create, the new association will be created in MySQL information schema REFERENCED_TABLE_NAME will be created case sensitively.

Example (note second to last column):

CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION POSITION_IN_UNIQUE_CONSTRAINT REFERENCED_TABLE_SCHEMA REFERENCED_TABLE_NAME REFERENCED_COLUMN_NAME
def mydb FK_E2C31786CF786E13 def mydb ObservationDiagnosticParameterValue diagnostic_parameter_value_id 1 1 mydb DiagnosticParameterValue id

However, if we add a new association, and do php vendor/bin/doctrine-module orm:schema-tool:update, the new association will be created in MySQL information schema REFERENCED_TABLE_NAME will be created case insensitively.

Example (note second to last column):

CONSTRAINT_CATALOG CONSTRAINT_SCHEMA CONSTRAINT_NAME TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME ORDINAL_POSITION POSITION_IN_UNIQUE_CONSTRAINT REFERENCED_TABLE_SCHEMA REFERENCED_TABLE_NAME REFERENCED_COLUMN_NAME
def mydb FK_E2C31786CF786E13 def mydb ObservationDiagnosticParameterValue diagnostic_parameter_value_id 1 1 mydb diagnosticparametervalue id

In the second case, we then get errors like this:

An exception occurred while executing 'INSERT INTO ObservationDiagnosticParameterValue (observation_id, diagnostic_parameter_value_id) VALUES (?, ?)' with params [1211, 6916]:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`mydb`.`ObservationDiagnosticParameterValue`, CONSTRAINT `FK_E2C31786CF786E13` FOREIGN KEY (`diagnostic_parameter_value_id`) REFERENCES `diagnosticparametervalue` (`id`))

#0 /var/opt/theapp/vendor/doctrine/dbal/lib/Doctrine/DBAL/Statement.php(140): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(PDOException), 'INSERT INTO Obs...', Array)

To fix this, we can alter the affected table like this:

alter table `ObservationDiagnosticParameterValue` drop foreign key `FK_E2C31786CF786E13`;
alter table `ObservationDiagnosticParameterValue` add constraint `FK_E2C31786CF786E13` foreign key (`diagnostic_parameter_value_id`) REFERENCES `DiagnosticParameterValue` (`id`);

The behavior of schema-tool:create and schema-tool:update should not be different.





[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-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-1000] MySQL DB cannot be created from Cli, returns "QLSTATE[42000] [1049] Unknown database" Created: 14/Oct/14  Updated: 26/Oct/14

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

Type: Bug Priority: Critical
Reporter: Marcus Malka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, mysql

Attachments: PNG File Screen Shot 2014-10-14 at 10.53.44.png    

 Description   

When trying to create a database via Symfony (tested 2.3, 2.4, 2.5) console using Doctrine, if returns

[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[42000] [1049] Unknown database 'livedb_ci_tco_dev'

This effectively prevents re-creating the database.

I traced the error, it seems database existence is either not checked or not functioning, and it tries to connect to the DB, resulting in an exception. In older versions the trace seemed like it checked if DB exists, and didn't try to connect.

I tested some different commit versions to assess where the bug was introduced - here is my brief list of working/non-working versions.

812dd9d (v.2.5.0-BETA3) fail
61eb1ee fail
3176f51 fail
da43b76 works
ce3a56e works
594e326 works
ba9aa63 (v.2.5.0-BETA2) works

So looking from the commit graph, to me it seems like it might have been introduced in commit 3176f51



 Comments   
Comment by Marco Pivetta [ 14/Oct/14 ]

Marcus Malka are you sure that you are running the correct command? If the DB is not there, I would expect an exception.

Comment by Christophe Coevoet [ 14/Oct/14 ]

Marco Pivetta This command is precisely about creating the database when it does not exist yet. I think this failure is related to the guessing of the platform version in DBAL 2.5, which will require connecting to the DB early.

Comment by Marco Pivetta [ 14/Oct/14 ]

Christophe Coevoet the screenshot shows the `drop` command being used

Comment by Marcus Malka [ 14/Oct/14 ]

I tested with multiple commands, mainly drop and create were most common.

The difference is in the error that gets produced with the different commits applied - other one gives the "The database is not there" kind of error you would expect. The other version gives an "can't do the operation because I can't connect to the database" even when you try to create it, and gives a similar "can't drop the database because I can't connect to the database" kind of error, which still says it tries to do something weird. My screenshot could've been taken from the create-command too, the error was identical.

I should have a breaking composer.json file in my version control on another machine. I'll try to add that later to facilitate debugging.

Comment by Steve Müller [ 14/Oct/14 ]

Christophe Coevoet you are right, that DBAL now connects early if you request the database platform but that should not be an issue as you may not specify a non-existing database name when connecting to creating a new database, anyways. And as far as I can see the CreateDatabaseDoctrineCommand even explicitly unsets the database name in the connection params here: https://github.com/doctrine/DoctrineBundle/blob/master/Command/CreateDatabaseDoctrineCommand.php#L71-L80 for a "temporary" connection.
Dropping a database still should require the database to be existent so connecting to it before dropping should be fine or am I missing something here?

Comment by Marcus Malka [ 15/Oct/14 ]

@Steve Muller - is it tries to create the connection and creates an error also when the database is not supposed to be there, for ex. in create action. Effectively breaking createDatabase command.

When I traced the code, it seemed to go in to the platform version checking, and seemed like it just didn't realize early enough that the DB isn't there (that was my guess - I don't know doctrine internals well enough to say if that's how it's planned to work or not).

Comment by Benjamin Eberlei [ 26/Oct/14 ]

This is an issue in DoctrineBundle that only appears in combination with DBAL 2.5.

The problem is Symfony apparently connects to the database in "Container::get" of the connection already. That has to be fixed.





[DBAL-844] [GH-549] Fix truncate on MySQL >= 5.5 Created: 22/Mar/14  Updated: 22/Mar/14

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

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


 Description   

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

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

Message:

When truncating tables on MySQL >= 5.5, an error is thrown:

```mysql
SQLSTATE[42000]: Syntax error or access violation:
1701 Cannot truncate a table referenced in a foreign key constraint ...
```

It turns out that with MySQL 5.5.7, `TRUNCATE` behaviour has changed. From the [MySQL docs](http://dev.mysql.com/doc/refman/5.5/en/truncate-table.html):

> TRUNCATE TABLE fails for an InnoDB table if there are any FOREIGN KEY constraints from other tables that reference the table. Foreign key constraints between columns of the same table are permitted.

With this PR foreign key checks are disabled just before and re-enabled just after truncate.

As I encountered this issue using doctrine/data-fixtures, I originally submitted a fix there: https://github.com/doctrine/data-fixtures/pull/127. However, as @deeky666 pointed out, the DBAL is a better place for the fix.






[DBAL-846] [GH-551] Foreign key checks on MySQL >= 5.5.7 for TRUNCATE Created: 24/Mar/14  Updated: 24/Mar/14

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

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


 Description   

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

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

Message:

  • Added `ConfigurablePlatform` interface to set the connection
    parameters to the Platform
  • Connection is now setting the parameters to the Platform if it
    implements `ConfigurablePlatform`
  • `MySQLPlatform::getTruncateSql()` now checks for a new param
    `disable_fk_checks`, if it is true and the version is affected, it
    automatically adds the required SQL.

Additional solution to https://github.com/doctrine/dbal/pull/549






[DBAL-798] [GH-520] [WIP] Add pdo informix driver support Created: 28/Jan/14  Updated: 28/Jan/14

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

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


 Description   

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

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

Message:

I have created this branch to add support to PDO_INFORMIX in DBAL.

First I had put a new topic in the doctrine-dev group (https://groups.google.com/forum/#!topic/doctrine-dev/gndS00nxSQA) where i explain some issues i have.






[DBAL-746] [GH-479] [DBAL-624] Fix parsing parameters in comments Created: 29/Dec/13  Updated: 29/Dec/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 deeky666:

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

Message:

Parameter placeholders should not be parsed out of comments in statements.






[DBAL-730] [GH-464] [DBAL-139] [WIP] Finish CACHE option implementation for sequences Created: 23/Dec/13  Updated: 23/Dec/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 deeky666:

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

Message:

@beberlei Started implementation for DBAL-139(http://www.doctrine-project.org/jira/browse/DBAL-139) in commit https://github.com/doctrine/dbal/commit/e8efcd7621e85003f3ce496bc26a108b53371838 and https://github.com/doctrine/dbal/commit/d397c005dd3ff3d48a81eeb47c2a0d74d6b7400d which was first drafted in PR #202. It's about adding a cache option for sequences.

*The following missing aspects of the implementation were added:*

  • SQL Server support
  • SQL Anywhere support
  • Reverse engineering the cache option with the schema managers
  • Comparator implementation
  • Schema::createSequence() adjustment
  • More tests

*Additional optimizations:*

  • Rename `$cache` to `$cacheSize` in Sequence (unified naming with `$allocationSize`)
  • More strict input validation for cache size values in Sequence to avoid SQL generation errors
  • Better API documentation
  • Unified `getSequenceCacheClause()` method on all platforms

*Todo:*

  • Fix comparator issues (see below)
  • Finish test suite for this (depends on comparator issues solution)

*Comparator issues*
The comparator will get into trouble when comparing cache size values. To get an understanding of this I'll first explain how cache size values evaluate to the database:

  • `null` -> No cache size specified, don't generate cache clause for sequences and use platform's default
  • `0` -> Explicitly disable caching for sequences, generates `NOCACHE` clause on platforms
  • every other positive value is an explicite specification of the cache size and results in `CACHE <size>` clause

Now there are two problems.

First one is that a value of `1` has a special meaning on some platforms, too. Oracle does not accept it and throws an error as the minimum allowed value is `2`. PostgreSQL allows a value of `1` but in fact interprets it as `NOCACHE`. SQL Server and SQL Anywhere accept a value of `1` but the behaviour is unclear compared to an explicite `NOCACHE` on these platforms. Now I am assuming that a cache size of `1` maybe also physically has the same effect as if specifying no cache at all and that this is more of a "compatibility" value and we maybe should not allow it at all to preserve portability throughout the vendors.

The second problem is the `null` value for `$cacheSize` in Sequences. This tells the vendor to use it's own specific default cache size which differs on all platforms. The comparator will always mark a sequence as changed then when `null` was initially defined for the sequence and the sequence is introspected from database again. This will lead to repeated `ALTER SEQUENCE` statements in the schema tool which is not good. Also we cannot determine in the platform itself if the sequence has really changed as there currently is no `SequenceDiff` class which could get passed to `AbstractPlatform::getAlterSequenceSQL()`. Instead we only get the changed sequence object. I have put together some [examples](https://gist.github.com/deeky666/6c4e47a275b1c9e7c068) to clarify on what I mean as it is hard to explain.

So I'm asking for opinions and input on this






[DBAL-715] Using caching with fetchColumn() of single row does not work Created: 20/Dec/13  Updated: 20/Dec/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

Issue Links:
Reference
is referenced by DBAL-468 [GH-288] Fix fetchColumn not caching Resolved

 Description   

The caching mechanism only triggers when the cursor is fully iterated and the result is closed. This breaks caching for code of the kind:

$cnt = $conn->executeQuery($sql)->fetchColumn();





[DBAL-624] Parameter in comments is parsed Created: 03/Oct/13  Updated: 22/Nov/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: Vitaliy Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-552 Colon (":") in field name treats like... Resolved

 Description   

Text in comment is parsed as params.
I.e.:
select abc – :par
from table

select abc /* :par */
from table



 Comments   
Comment by Steve Müller [ 21/Nov/13 ]

Which platform / driver do you refer to? Maybe a duplicate of this?
http://www.doctrine-project.org/jira/browse/DBAL-124

Comment by Vitaliy [ 22/Nov/13 ]

No platform / driver depend. I try test class SQLParserUtils in separate module. And this sql parsed wrong.





[DBAL-600] Add support of joins in update statements when using DBAL QueryBuilder Created: 09/Sep/13  Updated: 23/Dec/13

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

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


 Comments   
Comment by Steve Müller [ 23/Dec/13 ]

This is tricky as UPDATE statements based on JOINs are not in the SQL standard and therefore the syntax and support differs alot throughout the vendors. But could be doable with some effort.





[DBAL-599] Add support of insert and insert select statements in DBAL QueryBuilder Created: 09/Sep/13  Updated: 25/Nov/13

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

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

Issue Links:
Reference
relates to DBAL-182 Insert and Merge Query Objects Open
relates to DBAL-320 allow SQL QueryBuilder to do INSERTS Resolved
is referenced by DBAL-636 QueryBuilder insert Resolved




[DBAL-587] Support for Triggers, Views, Procedures Created: 27/Aug/13  Updated: 27/Aug/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Schema should have support for triggers, views and stored procedures. Since this is not standardizable accross platforms easily, the idea is to allow arbitrary SQL DDL Statements to be registered on a Schema, maybe even qualified by platform.

$artifact = new SQLArtifact();
$artifact->setName('some_view_name');
$artifact->create('CREATE VIEW IF NOT EXISTS foo SELECT 1');
$artifact->drop('DROP VIEW foo');
$artifact->setPlatforms("mysql"); // accepts string or array, if nothing is set applies to ALL platforms.
$schema->addSQLArtifact($artifact);

During the SQL generation for the schema, the following will be appended to the currently generated SQL:

DROP VIEW foo;
CREATE VIEW IF NOT EXISTS foo SELECT 1

The drop part of the statement is always rendered before the create statement in the Create Schema Visitor. In the Drop schema listener only the drop part is used.






[DBAL-547] Evaluate moving away from prepared statements to sprintf() Created: 18/Jun/13  Updated: 18/Jun/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   

We are using prepared statements and parsing on top at the moment to implement things like array param quoting and such.

We should evaluate if it makes sense to introduce a strategy for preparing/parsing queries and make sprintf() usage a default in 3.0 instead of using prepared statements. At least for MySQL the PHP Driver guys are arguing for this kind of processing for years.






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

Comment by Doctrine Bot [ 22/Dec/13 ]

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





[DBAL-324] SchemaManager should first look into comment instead of infer the type first. Created: 17/Aug/12  Updated: 03/Jan/14

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

Type: Bug Priority: Major
Reporter: 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

Comment by Steve Müller [ 03/Jan/14 ]

Steve Tauber You have defined a custom data type. You need to override `Type::requiresSQLCommentHint()` to return true in your custom data type, otherwise Doctrine cannot infer the custom type mapping from the column comment and the comparator will always detect changes between Yaml and LONGTEXT. This is not directly related to this issue here I think.
Guilherme Blanco I don't really get the issue you describe here. Is it maybe fixed already? Otherwise can you maybe try to explain again so that I can fix that?





[DBAL-321] [GH-184] Added INSERT support to dbal QueryBuilder Created: 13/Aug/12  Updated: 20/Dec/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 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.



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

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DBAL-294] [GH-163] [WIP] Upsert support protoype. Created: 29/Jun/12  Updated: 20/Dec/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 kimhemsoe:

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

Message:



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

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





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





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

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.

Comment by Steve Müller [ 28/Dec/13 ]

Benjamin Eberlei Do you still remember what is meant by this ticket? Could be solved already...





[DBAL-828] [GH-538] Json_Array: Convert database null to PHP null instead of empty array Created: 04/Mar/14  Updated: 24/Apr/14

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

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


 Description   

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

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

Message:

Related to https://github.com/doctrine/doctrine2/pull/968.



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

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

Comment by Doctrine Bot [ 24/Apr/14 ]

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

Comment by Steve Müller [ 24/Apr/14 ]

To be addressed in 3.0. We cannot change the behaviour in 2.x for BC reasons.





[DBAL-867] Doctrine\DBAL\Driver\Connection should be marked as an internal interface Created: 16/Apr/14  Updated: 26/Jun/14

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

Type: Documentation Priority: Major
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently, the main entry point Doctrine\DBAL\Connection is documented as a wrapper around Doctrine\DBAL\Driver\Connection.
This is very misleading and encourages other library to typehint against Doctrine\DBAL\Driver\Connection rather than Doctrine\DBAL\Connection. See https://github.com/symfony/symfony/pull/10720 for the original discussion.

However, the discussion in https://github.com/doctrine/dbal/pull/414#discussion_r7688765 implies that they should actually not be related together (but it cannot be fixed for BC reasons). The phpdoc should at least be changed



 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

This issue was fixed some time ago.

Commit reference: https://github.com/doctrine/dbal/commit/5fdedc4f8f304e8035580807bd36d59e97a87265

Comment by Steve Müller [ 22/Apr/14 ]

Guilherme Blanco How is your commit reference related to this issue?

Comment by Guilherme Blanco [ 22/Apr/14 ]

Steve Müller The suggestion about Doctrine\DBAL\Connection and Doctrine\DBAL\Driver\Connection started around the misleading support of ping and how to consistently support it across different drivers.
The commit reference I pointed out is Benjamin Eberlei's resolution to remove misleading phpdoc around ping support (which is also highlighted in the ticket as "phpdoc should at least be changed").
If there's anything else that is missing, I'm probably not seeing. All I've done is followed dbal's discussion. =\

Comment by Christophe Coevoet [ 22/Apr/14 ]

Your commit does not fix it at all. Benjamin Eberlei's comment was about the ping method only indeed. But he explained that Doctrine\DBAL\Connection should actually not be a Doctrine\DBAL\Driver\Connection except for legacy reasons, which is why makign it implement Doctrine\DBAL\Driver\PingableConnection was a bad idea even if it has a ping method.

My issue is related to the description of the class itself: https://github.com/doctrine/dbal/blob/aa2ed45ade6582a24e4f72f674f6989873d72112/lib/Doctrine/DBAL/Connection.php#L36
It still describes it as a wrapper around the driver connection, making other devs think that the right typehint in other libraries is the internal driver connection. See the discussion in the Symfony PR I linked

Comment by Guilherme Blanco [ 22/Apr/14 ]

So... it's reopened. I'll look into this later today.

Comment by Marco Pivetta [ 26/Jun/14 ]

Guilherme Blanco can you re-check this?





[DBAL-937] Make fieldDeclaration available in getName method of class Type Created: 11/Jul/14  Updated: 11/Jul/14

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: Dominic Tubach Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I've created a custom type that stores its data in a VARCHAR field. As requiresSQLCommentHint() returns true the value returned by getName() is used as type hint. If I change the length of the field in the entity mapping the scheme won't be updated because getName() still returns the same string. Now I would like to add the length to the returned string. Because this requires access to the fieldDeclaration I suggest to pass this array as paramater to getName().






[DBAL-446] Type json_array can't be null Created: 13/Feb/13  Updated: 06/Aug/14

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

Type: Bug Priority: Major
Reporter: Jan Hruban Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-966 [GH-655] json_array columns should re... Resolved

 Description   

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

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



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

This was fixed in 2.3.3

Comment by Joseph Wynn [ 06/Aug/14 ]

I'm seeing this behaviour again in v2.5.0-BETA3 (6d0b048). If I get time this week I can perform a bisect to figure out when it regressed.

Comment by Joseph Wynn [ 06/Aug/14 ]

Actually I don't think this was a regression; it looks like a fix was never made. I've opened a PR: https://github.com/doctrine/dbal/pull/655

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Doctrine Bot [ 06/Aug/14 ]

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

Comment by Marco Pivetta [ 06/Aug/14 ]

Re-opened, as this behavior seems reproducible also in 2.4.x

Comment by Steve Müller [ 06/Aug/14 ]

It was never fixed. That seems to have been a misunderstanding here. As pointed out by Marco Pivetta changing this behaviour is a BC break and can't be fixed before 3.0.





[DBAL-969] [GH-658] DBAL-968 Created: 11/Aug/14  Updated: 11/Aug/14

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

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


 Description   

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

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

Message:

The recent change to SQLServerPlatform.php (https://github.com/doctrine/dbal/commit/17dad30dc9acd91a5cda0da2c5ce2c40d522f766) broke the ORM Paginator's queries on SQL server.

I investigated, and found that some of the test cases for the SQL Server platform weren't actually correct SQL. Also, there were no test cases that covered what the paginator is doing, so I've written test cases for those. I will open a pull request for this issue.

The modifyLimitQuery method in SQLServerPlatform.php should be fixed to pass the fixed old tests and the new tests.

My concern is that that method is becoming too complex, but that's an issue for another day.






[DBAL-873] [GH-571] Introduced a Transaction object Created: 18/Apr/14  Updated: 23/Aug/14

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

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


 Description   

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

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

Message:

This is a first draft on the idea of a Transaction object, as suggested by @guilhermeblanco and @beberlei in doctrine/doctrine2#949.

This makes the following changes to `Connection`:

  • *Adds* the following methods:
  • `createTransaction()` : begins a transaction and returns the associated `Transaction` object
  • `getTransactionManager()` : returns the `TransactionManager`
  • *Deprecates* `beginTransaction()` in favour of `createTransaction()`
  • *Deprecates* the following methods, in favour of their counterparts on `Transaction`:
  • `commit()`
  • `rollBack()`
  • `setRollbackOnly()`
  • `isRollbackOnly()`
  • *Deprecates* the following methods, in favour of their counterparts on `TransactionManager`:
  • `isTransactionActive()`
  • `getTransactionNestingLevel()`
  • `setNestTransactionsWithSavepoints()`
  • `getNestTransactionsWithSavepoints()`

The new way of dealing with transactions is then:

$transaction = $connection->createTransaction();
$transaction->commit();

It also automatically propagates `commit()` and `rollback()` to nested transactions:

$transaction1 = $connection->createTransaction();
$transaction2 = $connection->createTransaction();
$transaction1->commit(); // will commit $transaction2 then $transaction1

Overall, it's not a complicated change, does not introduce any BC break, and passes all existing tests.

I'm looking forward to hearing what you think!



 Comments   
Comment by Doctrine Bot [ 23/Aug/14 ]

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





[DBAL-983] [GH-670] Handle default values for boolean, datetime, and datetimetz columns in PostgreSQL Created: 27/Aug/14  Updated: 28/Aug/14

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

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


 Description   

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

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

Message:

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

For example, the following statement:

`ALTER TABLE test_table ALTER test_column SET DEFAULT CURRENT_TIMESTAMP;`

Results in a column definition like:

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

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

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



 Comments   
Comment by Doctrine Bot [ 28/Aug/14 ]

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





[DBAL-512] Update schema not working on MsSql due to no support for alter identity Created: 06/May/13  Updated: 16/Dec/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: 1
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.



 Comments   
Comment by Steve Müller [ 25/Nov/13 ]

Obviously SQL Server doesn't support this. So what solution would you expect here? IMO such a scenario should be avoided as there is no reasonable way to deal with changing identity columns. I guess most people are not even aware of this. The solutions available are very risky (creating new schema and then migrating data for example) and can take very long to be finished and is extremly error prone. I don't know if we should support one of those workarounds.

Comment by Flip [ 27/Nov/13 ]

The bug is about the SQL statement that does not work.
1. One solution could be to prevent generating this statement and issue a warning instead. (not preferred)

Two other solutions are mentioned in that Stackoverflow post I mentioned, namely:
2. Create a new table with identity & drop the existing table
3. Create a new column with identity & drop the existing column

That is just the way things have to be done in SQL Server (unfortunately), so it wouldn't be a workaround. I think this is a very reasonable way and in fact similar solutions to similar problems have already been implemented into Doctrine. See http://www.doctrine-project.org/blog/doctrine-2-4-released.html "ALTER TABLE support for SQLite (by hason) by creating new tables, moving all the data and then renaming."

Comment by Benjamin Eberlei [ 13/Dec/13 ]

Flip not many people actually use Sqlite in production, its more of a "play database" with Doctrine, wheras SQL Server carries much more weigh. I don't want to implement this kind of workaround, Steve Müller what do you think is safe here?

Comment by Flip [ 13/Dec/13 ]

Not to argue .. but it's not a workaround

Really .. if it is ever implemented it would have to be in a few steps because SQL Server does not accept this one-line command like that. So basically when you don't want this solution it means that will never be implemented.

Talking about safe .. mind that the safety should also be ensured in other area's like 1. don't run --force on a production database 2. make backups. So when regarding the safety it's a very narrow area to take a look at. The operation could be setup in such a way that if the new table/column could not be created then the old one doesn't get deleted. That way you have always the safety like a database transaction.

I guess no point in making a Proof of Concept, because the general outline of the problem is actually not that complicated ..

Thx guys for the input on this issue.

Comment by Steve Müller [ 16/Dec/13 ]

Benjamin Eberlei we could of course use one of the approaches Flip mentioned, but the question is what to do in case something goes wrong during one of the steps required to alter an IDENTITY column. If it is acceptable that there exist "dead" tables/columns in case something goes wrong, we could try implementing that.





[DBAL-994] [GH-682] [WIP] [DBAL-218] Add bulk insert query Created: 30/Sep/14  Updated: 30/Sep/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 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/682

Message:

This is an approach to make use of database vendors' bulk row insert query syntax.
As the nature of bulk inserts usually is to insert a LOT of rows into a table (primarily from an external source), the implementation tries to focus on good performance and low memory consumption. It is NOT intended for `INSERT INTO ... SELECT ...` statement queries.

TODO:

  • Add an "executor" class that encapsulates the `BulkInsertQuery` object, adds options like bulk size and internally automatically evaluates the underlying platform's limits for a single `INSERT` statement and splits queries accordingly.
  • Evaluate platforms' max insert rows per `INSERT` statement and implement in platforms.
  • Add unit tests for quoted identifiers.
  • Add functional tests.

Future additions:

  • Add support for expressions.
  • Query builder (if there will be more bulk insert queries like `INSERT INTO ... SELECT ...`)?

Open for discussion. Ideas welcome!






[DBAL-982] [GH-669] Correct schema generation for altering PostgreSQL sequences Created: 25/Aug/14  Updated: 19/Oct/14

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

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


 Description   

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

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

Message:

I wrote a detailed explanation here so it is hopefully easy to follow:

        1. Background

With PostgreSQL there are three states for a column to receive a sequence generator: no generator, an internal shortcut towards generating an auto incrementing sequence (SERIAL), and a manually-created sequence. In its current state, DBAL accepts only a boolean "autoincrement" to its `getAlterTableSql()` method (via the passed-in `TableDiff`).

This results in the following scenario:

  • ORM maps a column to "AUTO" which is treated as a sequence (autoincrement = false)
  • DBAL `PostgreSqlSchemaManager` inspects existing table and notices a sequence (autoincrement = true)
  • Diff logic in `getAlterTableSql()` will always detect that autoincrement has changed, and that the requested value is false, so it will always issue a `DROP DEFAULT` statement

This is clearly a bug, and can be proved via a unit test; run the `AbstractPostgreSqlPlatformTestCase::testAlterSchemaSequenceToSequence` test that I have committed against the current DBAL code and you will see it fail (based on what is currently passed in via the ORM; see Q&A below for detailed explanation).

        1. Solution

There already existed a few references to a not-yet-implemented `sequence` property of a column definition, which would store the name of the sequence being used on the column. This makes sense and allows us to support all three column states with regards to sequence, while also preserving backwards compatibility. The default is always null, so it will result in no changes to functionality on other platforms.

So, this PR:

  • Adds the `Column::_sequence` property
  • Correctly sets that property during the `PostgreSqlSchemaManager::_getPortableTableColumnDefinition` method (it actually was already there, just not being used)
  • Checks the value during the `Comparator::diffColumn` operation
  • Uses the value to more correctly determine when to create/drop a sequence during a schema alter
  • Adds the appropriate unit tests to verify the six different combinations here
        1. Q&A

Is this just an ORM bug? Could the ORM be changed to just set autoincrement = true for the AUTO and SEQUENCE strategies?

This would solve the immediate problem, yes. However, it would leave no possible distinction between the three ORM mapping strategies of AUTO, SEQUENCE, and IDENTITY. Further, it would cause a break in `getAlterTableSql()` because setting autoincrement to true implies that we are using the database-generated identity sequence which has a specific name, thereby removing the ability for a user to define a sequence manually with a custom name and have it be used here. This strategy opens the door for addressing those cases later, and does not cause a BC break today.

This seems incomplete; for example, this still doesn't handle the case where a sequence is requested to change from AUTO to a specifically-named sequence.

That is intentional. I think these other cases could and probably should be handled, but they would require changes to both the DBAL and ORM. For example, we pass a `Sequence` object to the create/alter/drop sequence functions, but we do not pass one to the alter function. As a result, the actual sequence name is not available here, so we would absolutely need to make a more thought-out ORM change to solve this. I think that should be separate work, or it could just be something we do not support.

Won't this still require an ORM change to set the `sequence` property?

Yes, the following needs to be added to the `SchemaTool::gatherColumn` method:

```php
if ($class->isIdGeneratorSequence() && $class->getIdentifierFieldNames() == array($mapping['fieldName']))

{ $options['sequence'] = $class->sequenceGeneratorDefinition['sequenceName']; }

```

However, even without that change, this solves the problem on the DBAL side and opens the door to fixing the ORM to behave correctly here.

How do things behave today and how do we want them to behave with respect to alters?

This is what should happen in each alter scenario:

Existing State Mapped to AUTO or SEQUENCE Mapped to IDENTITY (Auto Increment) Regular Column
-------------- ----------------------- ----------------------------------- --------------
*No Sequence* Add Sequence; Default to `nextval(seqeuence)` Add Serial (Identity Sequence) No Change
*Default `nextval(seqeuence)`* No Change No Change Drop Default

This is what does happen today:

Existing State Mapped to AUTO or SEQUENCE Mapped to IDENTITY (Auto Increment) Regular Column
-------------- ----------------------- ----------------------------------- --------------
*No Sequence* No Change (Bad) Add Serial (Identity Sequence) No Change
*Default `nextval(seqeuence)`* Drop Default (Bad) No Change Drop Default


 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-947] [GH-634] Transaction object definition Created: 21/Jul/14  Updated: 19/Oct/14

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

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

Issue Links:
Reference
is referenced by DDC-2279 [GH-571] Update lib/Doctrine/ORM/Enti... Resolved

 Description   

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

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

Message:

To move forward with the Transaction Object, here is an alternative proposal to #571.

This keeps the same basic idea, but now `createTransaction()` returns a `TransactionDefinition` object, which is configurable, and has a `begin()` method that starts the underlying transaction and returns the `Transaction` object:

$tx = $em->createTransaction() // TransactionDefinition
->withIsolationLevel(Connection::TRANSACTION_SERIALIZABLE) // TransactionDefinition
->begin(); // Transaction

I think that this implementation checks all the boxes:

  • Clear separation between the Transaction and its Definition
  • Once the Transaction is created, its Definition is set and cannot be changed
  • No risk to forget to call `begin()`: if you do, you'll deal with a TransactionDefinition and just get a call to undefined method if you try to `commit()` it. Plus, your IDE will be able to warn you while coding.

And needless to say, we're still keeping 100% BC compatibility.

What do you think?






[DBAL-965] [GH-654] doModifyLimitQuery() was missing an outer "ORDER BY doctrine_rownum" Created: 06/Aug/14  Updated: 23/Oct/14

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

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


 Description   

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

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

Message:

Refer to:
http://www.doctrine-project.org/jira/browse/DBAL-940



 Comments   
Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DBAL-1033] [GH-716] Do not TRIM() parentheses around partial indexe conditions Created: 05/Nov/14  Updated: 05/Nov/14

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

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


 Description   

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

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

Message:

Because PostgreSQL will return the expression with a lot of
parentheses we cannot TRIM() them easily. It is easier and more
correct to adapt to what PostgreSQL returns. That means the declaration
of partial indexes must be updated as follow:

Before:
``options=

{"where": "other_id IS NULL"}

``

After:
``options=

{"where": "(other_id IS NULL)"}

``

And fore more complexe conditions, that would be:
``options=

{"where": "(((id IS NOT NULL) AND (other_id IS NULL)) AND (name IS NULL))"}

``






[DBAL-1035] [GH-718] implement method for retrying database queries/transactions Created: 05/Nov/14  Updated: 05/Nov/14

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

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


 Description   

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

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

Message:

It is best practice to implement retry logic for transactions that are aborted because of deadlocks or timeouts. This makes such method available inside the DBAL and also adds detection for errors where retrying makes sense in the different database drivers.

Deadlocks and timeouts are caused by lock contention and you often can design your application to reduce the likeliness that such an error occurs. But it's impossible to guarantee that such error conditions will never occur. This is why implementing retrying logic for such errors is actually a must when you have to ensure the application does not fail in edge cases or high load.
Some references where something similar has already been implemented:

I chose the name `retryable` because it is consistent with `transactional`. I think the implementation is quite straight forward and fits very well with the DBAL design.






[DBAL-1036] [GH-719] Added TraceLogger to get backtrace for executed queries Created: 05/Nov/14  Updated: 05/Nov/14

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

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


 Description   

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

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

Message:

Added a TraceLogger that returns a backtrace for the executed query.
The backtrace returns the last 10 frames, and it also formats the frames for easy reading






[DBAL-1038] [GH-720] Type json_array is not consistent with NULL values Created: 06/Nov/14  Updated: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: JSON, dbal

Issue Links:
Duplicate
is duplicated by DBAL-1037 Type json_array is not consistent wit... Resolved

 Description   

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

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

Message:

Fields of type json_array are often created as "TEXT NOT NULL", because they are not nullable by default.

If you have an existing table, and you add this field, all existing records will get an empty string as the value of the field and not NULL.
If you try to store a NULL value in that field, the database will convert it to an empty string.

The "convertToPHPValue" method for that type only checks for NULL when it converts NULL to array(), it does not check for an empty string.

The test must be changed to also test for the empty string, or else it behaves differently for when the column is set as nullable or not. And for the most common case, when the default vaule of letting the column be not nullable is used, this "feature" of converting blank values to empty arrays is not working.



 Comments   
Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DBAL-1030] [GH-713] Prevent result cache key collisions when sharing cache across different connections Created: 01/Nov/14  Updated: 10/Nov/14

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

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


 Description   

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

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

Message:

There's an issue when using the default cache key generation for the result cache and using the same cache system across different connections as the generated key will be the same regardless of the connection used.

We can solve this just by using the connection params in the key generation. This issue is quite similar to the one fixed in 1075(https://github.com/doctrine/doctrine2/pull/1075).



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DBAL-1042] [GH-724] Enable PostGIS extension for PostgreSQL tests Created: 10/Nov/14  Updated: 10/Nov/14

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

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


 Description   

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

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

Message:

This is more like a proposal. Since PostGIS is one of the most popular extensions of PostgreSQL, it might be a good idea to enable it on Travis and make sure DBAL works with it.

At the moment, DBAL's Schema Tool does not work with PostGIS because it cannot handle some VIEWS added by PostGIS.

See: https://travis-ci.org/jsor/dbal/jobs/40528527



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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





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

Status: Awaiting Feedback
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: 5
Labels: None


 Description   

Implemented support for Interbase/Firebird dialects






[DBAL-602] Deprecate Migrations in favor of stable tools Created: 12/Sep/13  Updated: 04/Dec/14

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DBAL-603 DbDeploy Support Sub-task Open Benjamin Eberlei  
DBAL-604 Liquibase Support Sub-task Open Benjamin Eberlei  
DBAL-605 Phinx Support Sub-task Open Benjamin Eberlei  

 Description   

The Migrations project is very big and currently unmaintained, even if there is definately need for a solution of the migration problem.

The idea would be introduce a subcomponent in DBAL that delegates this to proven tools (DbDeploy and Liquibase, and Phinx for PHP based).

The functionality Doctrine should provide is integration with the \Doctrine\DBAL\Schema API. Three operations come to mind:

  • status - What version are we? Do we need to execute more versions?
  • migrate - Execute the migration tool
  • create-migration - Create a new migration file of the underlying platform.

The last operation needs to check if no versions need to be applied at the moment.

interface MigrationTool
{
   /** @return MigrationCurrentStatus */
   public function getStatus();

   /** @return MigrationPerformedStatus */
   public function migrate($toVersion = null);

   /** @return MigrationRolledBackStatus */
   public function rollback($toVersion = null);

   /** @return MigrationCreatedStatus */
   public function create(Schema $toSchema);
}

Every tool implements this interface and then we need 3 new commands for "status", "migrate" and "rollback". The "create" command can only be implemented in the context of the ORM.



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

What is the idea here ?

I don't agree about removing the Migrations project in favor of using only the schema diff tool (which we already have as a command in the ORM btw). Migrating is not only about updating the schema. It also requires migrating data. Otherwise, it is not safe to use in production. This is why the

{doctrine:schema:update}

command displays a warning before running.
A good example is adding a new non-nullable unique field. Applying the schema update works on an empty DB but fails when the table already contains data.

Comment by Benjamin Eberlei [ 12/Sep/13 ]

Christophe Coevoet The idea is not to keep only ORM Schema-Tool, which is really only a Dev-Tool. We would rather add support for DbDeploy, Liquibase and Phinx into DBAL via some integration sub-component and using DBAL\Schema to create migration files for their formats.

Comment by Miha Vrhovnik [ 04/Jan/14 ]

There is also http://dbv.vizuina.com/

Comment by Jonathan Cardoso Machado [ 31/Jan/14 ]

The command line support is going to stay right? The idea here is to use third party deploy framework, but with specific bindings to use with Doctrine, Am I right?





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-603] DbDeploy Support Created: 27/Feb/13  Updated: 12/Sep/13

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

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


 Description   
  • DbDeploy Diff Generation
  • Schema Serialization
  • SchemaTool gets new event when diff is applied, then you can update a "stable" schema xml. On Generation new db deploy script, use current schema vs stable schema vom disc.





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-605] Phinx Support Created: 12/Sep/13  Updated: 18/Sep/13

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

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


 Comments   
Comment by Rob Morgan [ 18/Sep/13 ]

Hi Guys, I'm the lead developer for Phinx. Happy to give support here if needed.

Rob





Deprecate Migrations in favor of stable tools (DBAL-602)

[DBAL-604] Liquibase Support Created: 12/Sep/13  Updated: 04/Dec/14

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

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





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

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
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-225] Add events for onBeginTransaction, onCommit, onCommitFailure Created: 13/Feb/12  Updated: 04/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.2
Fix Version/s: 2.6
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-182] Insert and Merge Query Objects Created: 18/Nov/11  Updated: 04/Dec/14

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

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

Issue Links:
Reference
relates to DBAL-320 allow SQL QueryBuilder to do INSERTS Resolved
is referenced by DBAL-599 Add support of insert and insert sele... Open
is referenced by DBAL-636 QueryBuilder insert Resolved

 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: 04/Dec/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6
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-218] Add Object for BulkInsert Abstraction Created: 05/Feb/12  Updated: 04/Dec/14

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

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





[DBAL-217] Introduction Interface for Connection Created: 05/Feb/12  Updated: 04/Dec/14

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

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





[DBAL-1062] upgrade from v2.4.3 to v2.5.0 is forcing recreating Indexes making Doctrine unusable Created: 05/Dec/14  Updated: 12/Dec/14

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

Type: Bug Priority: Major
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: index
Environment:

any



 Description   

after executing 'composer update' i was upgraded to dbal v2.5.0
(im using "doctrine/orm": "~2.2,>=2.2.3" in composer.json)
im using Symfony 2.6.*

now when i try 'app/console doctrine:schema:update --dump-sql' i see that doctrine wants to recreate indexes on some tables for no practical reason
nothing changed in the code.

example:
DROP INDEX idx_a604da13a76ed395 ON table1;
CREATE INDEX IDX_B7E704F0A76ED395 ON table1 (user_id);
DROP INDEX uniq_b3319c7d77153098 ON table2;
CREATE UNIQUE INDEX UNIQ_C984F95777153098 ON table2 (code);

however when i try to execute this update, im getting this error:
General error: 1553 Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

this essentially prevents me from using automatic doctrine database mapping or using migration tools.



 Comments   
Comment by Marco Pivetta [ 05/Dec/14 ]

Downgraded to "Major", as this doesn't prevent usage of the DBAL at runtime.

You can still upgrade those indexes manually after having removed the FKs (to re-add them later on).

Seems like a case sensitivity issue of your setup: consider adding environment details.

Comment by Steve Müller [ 05/Dec/14 ]

Which database vendor are you using? Also interestingly the indexes get recreated with a different name. Thought of case sensitivity, too. I think the comparator nevertheless has to be adjusted to compare with identical case on index names.

Comment by gondo [ 05/Dec/14 ]

well it IS preventing me from using doctrine as it is.
i just downgraded dbal to v2.4.3 by adding "doctrine/dbal": "2.4.*", to my composer.js and everything is working fine. by that i mean, no commands to drop and create indexes.

im using mysql Ver 14.14 Distrib 5.6.21, for osx10.10 (x86_64) using EditLine wrapper

im developoing on OSX 10.10 and production is running CentOS.
i know that OSX is using case insensitive file system (i had to deal with it in the past when i was deploying to production)
but this time there is NO change in my code. zero. nothing.

if there was case sensitivity changes in dbal itself, that might be the problem, however that is nothing i can fix.

i would love to upgrade those indexes manualy, however i have no idea how to.
should i change something in the code? indexes were created and named by doctrine, not by me.
if you recommend updating database, that seems to be failing. i assume dropping indexes on live data might cause problems.
or is it safe to just drop and create these indexes in mysql cmd?

Comment by gondo [ 05/Dec/14 ]

i can not drop those indexes directly in mysql, im getting erros:
ERROR 1553 (HY000): Cannot drop index 'IDX_A604DA13A76ED395': needed in a foreign key constraint

Comment by Steve Müller [ 05/Dec/14 ]

okay just checked, casing is not a problem as identifiers will be lowercased automatically in Doctrine\DBAL\Schema\Table for comparison.
Need further information about the underlying database being used...

Comment by Steve Müller [ 05/Dec/14 ]

gondo please for now don't try to solve the issue automatically because it looks like a real issue we need to figure out. Otherwise there will be little chance we get to know the real cause of the issue...

Comment by gondo [ 05/Dec/14 ]

@Steve Müller for now i've solved it by downgrading dbal to v2.4.*
do you need some more information from me?
unfortunately i can't give you all the code, company policy + its quite big. but i can dump you database schemas and entity declarations of affected tables if that will help. please let me know.

Comment by Steve Müller [ 05/Dec/14 ]

Hmm cannot reproduce the problem. What I did:

composer create-project symfony/framework-standard-edition path/

then added 'doctrine/dbal": "2.4.*"' to composer.json

composer install

then created entity with unique column name (to force auto index generation)

php app/console doctrine:database:create
php app/console doctrine:schema:create

then changed 'doctrine/dbal": "2.4."' to 'doctrine/dbal": "2.5."' in composer.json

php app/console doctrine:schema:update --force
Nothing to update - your database is already in sync with the current entity metadata.

Tried that with pdo_mysql on ubuntu 14.04 x86_64.

Comment by gondo [ 05/Dec/14 ]

were you creating some tables with foreign keys?

Comment by gondo [ 05/Dec/14 ]

here is the list of all indexes what tries to be recreated:
http://pastebin.com/nFYp6pnp

here are the definitions of some entities + their schemas and indexes from mysql:
notification_channel
http://pastebin.com/EfkcyUnf
http://pastebin.com/Ngd1Lkbe

online_payment_option
http://pastebin.com/R5waCF35
http://pastebin.com/ti4TzyKX

user_settings
http://pastebin.com/gxed5kjY
http://pastebin.com/EiCBWKNQ

i've also tried to specify index with custom name as per http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-index
to prevent this index recreation but without no luck, it was ignored.
i've tried to change the definition of `online_payment_option` table like this:
@ORM\Table(name="online_payment_option", options=

{"collate"="utf8_unicode_ci", "charset"="utf8"}

, indexes={@ORM\Index(name="TEST", columns=

{"code"}

)})
but after trying schema:update im still getting the same output http://pastebin.com/nFYp6pnp

Comment by Steve Müller [ 12/Dec/14 ]

Okay I think I get the problem now. I don't get any suggested update statements when upgrading from a DBAL 2.4 created schema to DBAL 2.5.
I assume this is because even in DBAL 2.4 the indexes are created with the name your update command suggests. For example:

DROP INDEX idx_a604da13a76ed395 ON notification_channel;
CREATE INDEX IDX_B7E704F0A76ED395 ON notification_channel (user_id);

You have an index named idx_a604da13a76ed395 in your database, the index name DBAL generates is IDX_B7E704F0A76ED395. Even in 2.4 this is the name that is generated by DBAL. The reason why you get those update statements is because index names are compared since DBAL 2.5 as part of the new index renaming feature.
I guess that the index name generation has changed in an earlier version of DBAL (can't prove that right now). So you probably created the index with a much earlier DBAL version back then and now it wants to rename it. This should be a one time "upgrade" step.
The reason why manually defining an index in your entity with a custom name has no effect is because ORM's schema tool prefers auto generated indexes over custom indexes if both fullfill the same criteria. This is something to be fixed in ORM then.
The foreign key problem is indeed something we have to deal with in DBAL. The update schema command should create SQL to first drop FKs, then rename indexes and afterwards recreate FKs again.
Hope that helps for now. Sorry for the upgrade circumstances...

Comment by gondo [ 12/Dec/14 ]

thank you very much for looking into this and spending time on it!
it is very likely that those indexes were created in older version, however I'm 100% that it is not older than 1 year.

if i understand correctly, there are several things what needs to be fixed (manual overwriting of indexes and generating proper update schema command)

is this something what will be fixed? or does this fall into "edge case" bucket and will be left until more people experience same problem?
so far I'm fine staying on 2.4.3 but eventually i would like to upgrade. if the fix is planned, i can wait. if not, than i can create manual update now.

thanks one more time

Comment by Steve Müller [ 12/Dec/14 ]

I am already on that foreign key issue. As soon as that is fixed, the generated update SQL should be valid so that it can safely be run and you don't need to update your index names manually then. As what the manual index preference is concerned that needs to be fixed in ORM. I might also have a look into this issue afterwards. I think it won't take long until DBAL 2.5.1 as there is another critical issue that needs to be adressed sonner than later.
With 2.5.1 you should be safe to update your schema automatically.

Comment by gondo [ 12/Dec/14 ]

perfect!
thats much sooner than i expected
thanks again





[DBAL-1074] [GH-743] Add failing unit test related to DBAL-1063 Created: 14/Dec/14  Updated: 14/Dec/14

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

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


 Description   

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

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

Message:

I am not 100% sure, but I think the behavior exposed by this test is one of the factors in DBAL-1063. But even if it wasn't, it is still very confusing that `Table::getIndexes` doesn't return the same thing as `SchemaManager::listTableIndexes` when they are both called on the same table.

I've written the test against the MySQL SM, but I suspect the same might happen with other platforms as well






[DBAL-1063] Exceptions from SchemaTool when running with DBAL 2.5.0 Created: 06/Dec/14  Updated: 15/Dec/14

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

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


 Description   

I'm not entirely sure it it is related to DBAL-1062, but I'm seeing some similar problems since updating to 2.5.0. The problem I'm having occurs only once per table, and only for some tables, so it is kind of hard to debug. What I've found out so far is that it happens when I manually define an index on a column which I name f.x. 'colname_idx', and then later Doctrine wants to add an index to the column automatically (e.g. when it is an association field), in which case it generates an index name like 'IDX_CF2713FD16F4F95B'.

An index with this name already exists (from the last run of the SchemaTool, presumably). The isFullfilledBy function in Doctrine\DBAL\Platforms\AbstractPlatform\Index detects that the both the manually-named index and the automatically-named one are identical and thus ignores them in Doctrine\DBAL\Schema\Table::_addIndex.

When the schema read from the database is compared to the one generated from metadata in Doctrine\DBAL\Schema\Comparator::diffTable, $table1 will list 'colname_idx' and the one from $table2 will say 'IDX_CF2713FD16F4F95B'. So it will be counted as a rename, and the rename SQL (for mysql at least) is

DROP INDEX colname_idx ON tablename
CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)

But as mentioned before, IDX_CF2713FD16F4F95B already exists, so I get

  [Doctrine\DBAL\Exception\DriverException]                                                          
  An exception occurred while executing 'CREATE INDEX IDX_CF2713FD16F4F95B ON tablename (colname)':          
  SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'IDX_CF2713FD16F4F95B'

Since the DROP statement before was executed successfully, on the next SchemaTool run, the existing index will be detected correctly for $table1, and thus no rename is issued.



 Comments   
Comment by Steve Müller [ 08/Dec/14 ]

From a first glance this issue is caused by ORM's schema tool which is creating indexes implicitly for unique columns and associations. Seems it doesn't play well with the new index renaming feature from DBAL 2.5 if you also define indexes explicitly that also fullfill those auto generated ones.
Maybe we have to asjust the schema tool to make a certain preference of explicitly defined indexes over auto generated ones if both fullfill the same criteria.

Comment by flack [ 08/Dec/14 ]

Well, making the schema tool smarter is certainly a good idea, since in 2.4 it created duplicate indexes (different name, same function) if I understood your theory correctly.

But there are some things on the DBAL side that I wonder about, e.g. shouldn't dbal do a sanity check before renaming? Or is there one that doesn't trigger because it cannot detect that an index with the target name already exists?

As far as I understood it, the schema read from the database was missing the one index (auto-generated one by SchemaTool), because Doctrine\DBAL\Schema\Table::_addIndex refused to add it on the grounds that it isFullfilledBy the manually-created index. This sounds like a very valid optimization for the case where I plan to write a schema to the database, but it is not at all helpful when creating a representation of an existing database. So I wonder if this case shouldn't be handled differently.

The other thing I'm still unclear about is why the second schema (the one coming from the driver) has the autogenerated index instead of the manual one. I suppose it could be a timing issue, but if the driver and the schematool both were to call _addIndex in the same order, the issue wouldn't even occur. Which might make it difficult to write a unit test for it

Comment by Steve Müller [ 09/Dec/14 ]

flack I did not test anything about this issue yet. It's all just speculation at the moment. What we'll have to do is try reproducing it in a test case. I would propose adding a test case to ORM first as this is your main entry point. Would be awesome if you could PR such a test case that reveals the issue then we can make further inspections. Still not sure whether it's a DBAL or ORM issue or maybe even both...

Comment by flack [ 15/Dec/14 ]

I've added two tests now:

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

The first one shows a discrepancy between Table::getIndexes and SchemaManager::listTableIndexes (which might be the root cause of the problem), and the second one reproduces the exception mentioned above.

BTW: Is there a way to make Jira recognize that a PR belongs to an already existing ticket? Right now, it always seems to create a new issue for each pull request





[DBAL-1076] [GH-745] Added doModifyLimitQuery for SQLServer2012Platform that uses OFFSET... FETCH Created: 16/Dec/14  Updated: 16/Dec/14

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

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


 Description   

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

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

Message:

SQL Server 2012 introduced new syntax for paging records using the OFFSET... FETCH clause. See http://technet.microsoft.com/en-us/library/gg699618%28v=sql.110%29.aspx for details on the specification.

This pull request:

  • Adds doModifyLimitQuery specific to SQLServer2012Platform, using OFFSET ... FETCH instead of ROW_NUMBER() OVER(blah blah)
  • Duplicates tests from SQLServerPlatformTest, using simpler OFFSET ... FETCH syntax

This version of doModifyLimitQuery will be much more robust than the one for SQLServer 2008 and below.






[DBAL-1079] [GH-747] minor phpdoc fixes in the schema files Created: 16/Dec/14  Updated: 16/Dec/14

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

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


 Description   

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

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

Message:

Some minor phpcs fixes in the dbal schema files






[DBAL-1087] [GH-751] Length of fixed string type (char) is ignored on Postgre schema update Created: 19/Dec/14  Updated: 19/Dec/14

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

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


 Description   

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

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

Message:

This PR should fix an issue for the fixed string type columns using PostgreSQL.

I've created a basic Symfony 2.6. Application and using a PostgreSQL 9.3. database. In this dummy project, I've created the following Entity:

``` php
<?php

namespace Acme\DemoBundle\Entity;

use Doctrine\ORM\Mapping AS ORM;

/**

  • @ORM\Entity
  • @ORM\Table(name="test")
    */
    class Test
    {
    /**
  • @ORM\Id
  • @ORM\Column(type="integer", name="id")
  • @ORM\GeneratedValue
    */
    public $id;

/**

  • @ORM\Column(type="string", name="name", length=2, options= {"fixed" = true}

    )
    */
    public $name;
    }
    ```

The table is successfully created after a schema update, but when another schema update is executed without any changes to the entity, an ALTER query is executed:

``` sql
ALTER TABLE test ALTER name TYPE CHAR(2);
```

After I searched in the code of doctrine dbal, I discovered that the length of the char column is not fetched correctly in `PostgreSqlSchemaManager::_getPortableTableColumnDefinition()`. In my example, length results as `null` and will be later set to 255 in the `Comparator`, which isn't the correct length from the database column. The comparation of the schemas results in a change of char-length.

For simplicity, I extended the if-condition in `PostgreSqlSchemaManager` to:

``` php
if (strtolower($tableColumn['type']) === 'varchar' || strtolower($tableColumn['type']) === 'bpchar') {
```

The fix I've contributed does help to parse the length in my case, but when I look into `PostgreSqlPlatform::initializeDoctrineTypeMappings()` there could be other types with the same problem, that are mapped to the doctrine string type.

``` php
// ... part of PostgreSqlPlatform::initializeDoctrineTypeMappings()
'varchar' => 'string',
'interval' => 'string',
'_varchar' => 'string',
'char' => 'string',
'bpchar' => 'string',
'inet' => 'string',
```

I guess we need to cover `char` and the others too.

`PostgreSqlSchemaManagerTest` also doesn't cover existing code. How is this going to be tested? Does the SchemaManagers need some tests in general?






[DBAL-1081] Paginator - Query Limit for SQL Server - SqlServerPlatform.php Created: 16/Dec/14  Updated: 18/Dec/14

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

Type: Bug Priority: Major
Reporter: Maciej Grajcarek Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, dql, orderBy, sqlserver
Environment:

Windows



 Description   

Hi!
I have a problem with Query results limit when ordering by SUM of a field.

My query looks like this:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

First I was catching following error:
message: "[Syntax Error] line 0, col 395: Error: Expected known function, got 'SUM'"
class: Doctrine\ORM\Query\QueryException

It only accourse if SUM is used in ORDER BY clause.

I have registered new class Sum which extends FunctionNode.

Now, query is build and executed but it has an error:

'SELECT * FROM 
     (SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY value) DESC) AS doctrine_rownum FROM yellowpage_keywords y0_ INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id INNER JOIN listings l2_ ON y1_.listing_id = l2_.id WHERE l2_.customer_id = ? AND y0_.origin_date >= ? AND y0_.origin_date <= ? GROUP BY y0_.name_crc, y0_.name) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10 ORDER BY doctrine_rownum' with params ["111", "2013-01-01 00:00:00.000000", "2014-12-31 23:59:59.000000"]

The line :

ROW_NUMBER() OVER (ORDER BY value) DESC)

should look like

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC)

In doModifyLimitQuery method I have modified:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', $column['table'], $column['column']);

to:

                $pattern = sprintf('/%s\.%s\s+(?:AS\s+)?([^,\s)]+)/i', str_replace('(', '\(', $column['table']), str_replace(')', '\)', $column['column']));

Now preg_match founds matching strings and OVER part of query is build correctly.

I checked other issues about this problem (which are marked as already fixed) and I have no idea why it's not working for me.

Thanks in advance!



 Comments   
Comment by Marco Pivetta [ 17/Dec/14 ]

Seems like a bit of information is missing: Is this issue related to the paginator API or not?

Comment by Maciej Grajcarek [ 17/Dec/14 ]

First of all - thank you for formatting my issue.
Secondly yes - issue is directly connected with paginator API.

Here is a code which should help you to replicate the problem:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY SUM(ypk.value) DESC

        $dql = $this->getEntityManager()->createQuery($query);
        $dql
            ->setParameter('customerId', $customerId)
            ->setParameter('dateFrom', $dateFrom)
            ->setParameter('dateTo', $dateTo);
        $dql->setMaxResults(10);    

        $keywords = $dql->getArrayResult(); 
Comment by Marco Pivetta [ 17/Dec/14 ]

That doesn't involve the paginator, just DQL.

SUM() and computed values are not supported in the ORDER BY clause: you have to select them first. Try:

            SELECT ypk.name keyword, SUM(ypk.value) total
            FROM YpBundle:YellowPageKeyword ypk
              JOIN ypk.yellowpage yp
              JOIN yp.listing l
            WHERE l.customer = :customerId
              AND ypk.originDate >= :dateFrom
              AND ypk.originDate <= :dateTo
            GROUP BY ypk.nameCrc, ypk.name
            ORDER BY total DESC
Comment by Maciej Grajcarek [ 18/Dec/14 ]

If I will do it, it will result in a following query:

SELECT *
FROM (
	SELECT y0_.name AS name_0, SUM(y0_.value) AS sclr_1, ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum 
	FROM yellowpage_keywords y0_
	INNER JOIN yellowpages y1_ ON y0_.yellowpage_id = y1_.id
	INNER JOIN listings l2_ ON y1_.listing_id = l2_.id
	WHERE l2_.customer_id = 111
		AND y0_.origin_date >= '2014-01-01'
		AND y0_.origin_date <= '2014-12-01'
	GROUP BY y0_.name_crc, y0_.name
) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1 AND 10
ORDER BY doctrine_rownum

It's an incorrect query for an SQL Server. Take a look on this part:

ROW_NUMBER() OVER (ORDER BY sclr_1 DESC) AS doctrine_rownum

SQL Server do not support aliasing in OVER clause.

It should look like this, to work:

ROW_NUMBER() OVER (ORDER BY SUM(y0_.value) DESC) AS doctrine_rownum

It looks like this is the copy of this issue: http://www.doctrine-project.org/jira/browse/DBAL-788
I'm on doctrine version 2.5 which has patch from that issue included, but I have no idea why it's not working for me.





[DBAL-1086] [GH-750] Store the parameters of the chosen connection when using Master/Slave. Created: 19/Dec/14  Updated: 19/Dec/14

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

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


 Description   

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

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

Message:

When using the MasterSlaveConnection, the internal parameters array has a different structure than the usual Connection. This can cause the following methods to fail: getHost(), getPort(), getUsername() and getPassword().

I changed the MasterSlaveConnection so that it stores the parameters of the chosen connection in a private property. With this change, the methods that used to fail can now retrieve the configuration for the actual chosen connection, which is, in my opinion, clearly the expected behavior.

I chose to create a new private property in MasterSlaveConnection instead of inherit the $_params from Connection in order to not cause any confusion by having two different array structures in the same variable at different situations.

I also expanded the tests for this case.






[DBAL-1088] [GH-752] Fix error handling restore Created: 19/Dec/14  Updated: 19/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 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/752

Message:

PHP already handles an internal stack of error handlers






[DBAL-1083] [GH-749] [DBAL-1082] Fix SchemaTool does not generate SQL for MySQL unsigned float Created: 18/Dec/14  Updated: 18/Dec/14

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

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


 Description   

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

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

Message:






[DBAL-1084] MySQL DateTime fractional seconds exception Created: 18/Dec/14  Updated: 19/Dec/14

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

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

MySQL 5.6.4+



 Description   

Since MySQL 5.6.4 it is possible to include fractional seconds in datetime/timestamp fields.

Doctrine cannot handle this at the moment, and it is not clear how this can be resolved.

Doctrine\DBAL\Types\ConversionException(#67): Could not convert database value "2014-12-16 17:06:38.385" to Doctrine Type datetime. Expected format: Y-m-d H:i:s
  #0 /var/www/vendor/doctrine/dbal/lib/Doctrine/DBAL/Types/DateTimeType.php(67): Doctrine\DBAL\Types\ConversionException::conversionFailedFormat('2014-12-16 17:0...', 'datetime', 'Y-m-d H:i:s')
  #1 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(330): Doctrine\DBAL\Types\DateTimeType->convertToPHPValue('2014-12-16 17:0...', Object(Doctrine\DBAL\Platforms\MySqlPlatform))
  #2 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(359): Doctrine\ORM\Internal\Hydration\AbstractHydrator->gatherRowData(Array, Array, Array, Array)
  #3 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php(179): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData(Array, Array, Array)
  #4 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(140): Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData()
  #5 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(804): Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll(Object(Doctrine\DBAL\Driver\PDOStatement), Object(Doctrine\ORM\Query\ResultSetMapping), Array)
  #6 /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php(574): Doctrine\ORM\AbstractQuery->execute(NULL, 1)
  #7 /var/www/index.php(142): Doctrine\ORM\AbstractQuery->getResult()

The solution for MsSQL (see DBAL-860) cannot be used, because the fractional seconds definition can be different across fields:

  `insert` timestamp NULL DEFAULT NULL,
  `update` timestamp(3) NULL DEFAULT NULL,
  `delete` timestamp(5) NULL DEFAULT NULL,

My current approach is to create a custom type, but I would like to create a solution in Doctrine.

Any thoughts on this?



 Comments   
Comment by Marco Pivetta [ 18/Dec/14 ]

We don't currently support this nor can support a change in the DateTime type in 2.x. If you want support for this, then I suggest using a custom type (as you are doing) or proposing something new for 3.x

Comment by Jachim Coudenys [ 19/Dec/14 ]

For anyone that is having the same issue, I've added my version of the custom mapping in a Github Gist.





[DBAL-1080] [GH-748] minor phpdoc fixes in the remaining files Created: 16/Dec/14  Updated: 19/Dec/14

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

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


 Description   

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

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

Message:

This pr fixes the remaining phpcs issues left after #746 & #747



 Comments   
Comment by Doctrine Bot [ 19/Dec/14 ]

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





[DBAL-1089] [GH-753] Add a unit test for broken backslashes on MySQL in LIKE Created: 19/Dec/14  Updated: 19/Dec/14

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

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


 Description   

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

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

Message:






[DBAL-837] Cannot drop index needed in a foreign key constraint Created: 17/Mar/14  Updated: 17/Mar/14

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

Type: Bug Priority: Minor
Reporter: Cliff Odijk Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MariaDB version 10.0.7
InnoDB version 5.6.10
doctrine/orm version v2.4.1
doctrine/dbal version v2.4.2


Issue Links:
Reference
relates to DBAL-732 MySQL 5.6 - Cannot change column 'fkP... Open

 Description   

I'm trying to remove an relation from an entity and i'm getting an error that it could not be executed. After testing it, it's missing the DROP FOREIGN KEY query.

The generated SQL is:

DROP INDEX IDX_DCE815B325C79A8C ON moveMembers;
ALTER TABLE moveMembers DROP fkAccessId;

When I use --force to execute it I get the following error:

[Doctrine\DBAL\DBALException]
An exception occurred while executing 'DROP INDEX IDX_DCE815B325C79A8C ON moveMembers':

SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint

[PDOException]
SQLSTATE[HY000]: General error: 1553 Cannot drop index 'IDX_DCE815B325C79A8C': needed in a foreign key constraint



 Comments   
Comment by Cliff Odijk [ 17/Mar/14 ]

Maybe related to DBAL-732?





[DBAL-631] NuoDB compatibility Created: 15/Oct/13  Updated: 15/Oct/13

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

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


 Description   

Hello,

I'm looking for a scalable SQL database, and I found nuoDB(old nimbus DB) that seems to do the job on paper.
My company tend to encourage us to move to many small VM architecture in place of large machines.

I wanted to know if such a DB engine was going to be supported in the near future, or if it was now.
For what I saw, the only really scalable solution I have now is nosql DB as mongo DB with doctrine.
As Doctrine is a requirment on our application, I was condering if you had any feedback for us on this subject.

Best regards, and thank you for your work.

Pierre Bonneau



 Comments   
Comment by Christophe Coevoet [ 15/Oct/13 ]

The best way to have NuoDB support in DBAL is probably to contribute it.
Introducing new drivers is best done by people using them (because they actually need it, and because they can more easily test them)

You will need to provide 3 classes (and their tests):

Comment by Pierre Bonneau [ 15/Oct/13 ]

Hello,

I already asked the question to NuoDB company, waiting their answer.
I'm absolutly not familiar with it, so I'm not very confident in the fact I would be able to provide a correct interface for this server.

I read mysql driver, shema and platform as an example. Driver and shema development should be dueable... but platform is totally out of my scope / scope... It would require a good knowledge of the database, and honnestly, I need only to perform 3 operations on it : INSERT / UPDATE and SELECT... without even a join. Would it be possible to let the other method empty and to let the community fill the blank ?

Thank you,
Pierre

Comment by Christophe Coevoet [ 15/Oct/13 ]

unfortunately, you need more than this in case you are using the ORM, because the ORM needs more methods from the platform (many of them has been added based on the needs of the ORM). However, the nuodb doc should only implementing these methods: doc.nuodb.com/display/doc/SQL+Reference

Comment by Pierre Bonneau [ 15/Oct/13 ]

Hello,

Thank you for your answer...

If we want to be compliant to Doctrine, is there a number of method that are required, and some other that are usefull?
I mean I can implement the method, but do nothing in some of them. The next user who need more will develop the module, or we will do later if needed.

The idea for me is to lower the cost, and to not pay on my project budget the entire connectivity...
I'm not againts speding 3-5 man day in this subject, but more will be an issue regarding the total amount of day I have on the project.

Pierre





[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-319] Doctrine\DBAL\Types\Type Created: 12/Aug/12  Updated: 22/Dec/13

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.

Comment by Steve Müller [ 22/Dec/13 ]

API cleanup and staticness can be addressed in 3.0 for the first time. Otherwise we cannot keep BC. You can use Doctrine\DBAL\Types\Type::overrideType('someType', null); as a workaround for removing a type from the registry.





[DBAL-292] Multiple use of named parameter doesn't work Created: 12/Jun/12  Updated: 28/Dec/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?

Comment by Steve Müller [ 28/Dec/13 ]

Jürgen ping. I cannot reproduce this error, either. Can you please try to reproduce this with the latest master branch? Otherwise I will close this ticket.





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

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.

Comment by Steve Müller [ 28/Dec/13 ]

I don't think we can fix this in DBAL. We should leave the decimal values retrieved from database as string for the obvious conversion problems. AFAIK the documentation in ORM has also been updated. Don't know about ORM issues with entity updates, but I don't see any further todo here in DBAL. Can this ticket be closed?

Comment by Oleg Namaka [ 28/Dec/13 ]

@Steve Muller, is it feasible to change the way decimal values are compared from strict === to == to mitigate the issue with unnecessary updates:

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 a very serious Doctrine shortcoming as for every single entity that has at least one decimal field with no real value changes updates still will be issued.

Comment by Steve Müller [ 28/Dec/13 ]

Oleg Namaka I understand that. But IMO this is an issue that has to be adressed in ORM because casting the values in the DBAL type breaks the precision/correctness of the original database value in some circumstances. Therefore the only possible solution can be to fix this in ORM IMO.





[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-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-954] Custom QuoteStrategy doesn't work when creating new schema Created: 30/Jul/14  Updated: 30/Jul/14

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

Type: Bug Priority: Minor
Reporter: Piotr Łyczba Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: schematool


 Description   

Implementing custom quote strategy:

class SingleQuoteStrategy extends DefaultQuoteStrategy implements QuoteStrategy
{
    public function getColumnName($fieldName, ClassMetadata $class, AbstractPlatform $platform)
    {
        return isset($class->fieldMappings[$fieldName]['quoted'])
            ? $platform->quoteSingleIdentifier($class->fieldMappings[$fieldName]['columnName'])
            : $class->fieldMappings[$fieldName]['columnName'];
    }
}

doesn't work when a new schema is created.

The problem is that in class file mapping I have column that has dot in its name escaped with back single quotes:

<field name="anuncianteId_delete" type="integer" column="`anunciante_id.delete`" nullable="true"/>

My custom quote strategy is necessary to force Doctrine to respect that. Otherwise Doctrine treats it as: namespace.name.

If I already have table with that column in my database update schema tool doesn't complains, the problem occurs only when I try to create new schema.

The error in resulting SQL Statement:

(SQLSTATE[HY000]: General error: 1 near ".": syntax error' while executing DDL: CREATE TABLE account ( (...) "anunciante_id"."delete" INTEGER DEFAULT NULL, (...) )





[DBAL-732] MySQL 5.6 - Cannot change column 'fkProjectId': used in a foreign key constraint Created: 24/Dec/13  Updated: 18/Mar/14

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

Type: Bug Priority: Minor
Reporter: Cliff Odijk Assignee: Steve Müller
Resolution: Unresolved Votes: 2
Labels: None

Issue Links:
Reference
is referenced by DBAL-837 Cannot drop index needed in a foreign... Open

 Description   

I'm using doctrine migrations to change a null field to a not null field. MySQL 5.6 is strict on altering tables with foreign key constraint's.

Generated SQL

ALTER TABLE badges CHANGE fkProjectId fkProjectId INT NOT NULL

Result in the following error

Cannot change column 'fkProjectId': used in a foreign key constraint 'FK_1483A5E9F28AE4EA'

More info:

As of 5.6.7, the server prohibits changes to foreign key columns with the potential to cause loss of referential integrity. A workaround is to use ALTER TABLE ... DROP FOREIGN KEY before changing the column definition and ALTER TABLE ... ADD FOREIGN KEY afterward.

Original issue:



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

Cliff Odijk what versions of DBAL/ORM are affected by the bug?

Comment by Cliff Odijk [ 24/Dec/13 ]

Doctrine 2.3.4 / 2a37b007dda8e21bdbb8fa445be8fa0064199e13.

Comment by Steve Müller [ 27/Dec/13 ]

Marco Pivetta I wonder whether we should introduce MySqlPlatform567 to fix this which adds this behaviour. We could also fix this is MySqlPlatform directly but I don't know if this impacts performance for older versions of MySQL that don't require this behaviour.

Comment by Timothée Martin [ 09/Jan/14 ]

I encounter the same issue with doctrine/dbal 2.4.2 (commit fec965d330c958e175c39e61c3f6751955af32d0).

Have you any idea of when this bug will be fixed? Or may be can you guide me on how to fix it and I could make a PR on doctrine/dbal.

Thanks.

Comment by Steve Müller [ 09/Jan/14 ]

Cliff Odijk , Timothée Martin I will work on this issue as soon as I have time. Expect a fix for this in the upcoming weeks. Thank you for your patience.

Comment by Cliff Odijk [ 28/Jan/14 ]

The same error occurs with MariaDB version 10.0.7

  • InnoDB version 5.6.10
  • doctrine/orm version v2.4.1
  • doctrine/dbal version v2.4.2
Comment by Steve Müller [ 18/Mar/14 ]

I already started work on this but didn't have time to finish it, yet. I will try to find some time for this this evening.





[DBAL-903] php app/console doctrine:migration:diff generates redundant sql queries for postgres Created: 12/May/14  Updated: 26/Oct/14

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

Type: Bug Priority: Minor
Reporter: Hanov Ruslan Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

php app/console doctrine:migration:diff

generates redundant sql queries for postgres

symfony 2.4.2,
postgres 9.3
doctrine/orm: ~2.2,>=2.2.3
doctrine/doctrine-bundle: 1.2.*
doctrine/migrations: dev-master
doctrine/doctrine-migrations-bundle: dev-master

    public function up(Schema $schema)
    {
      
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql", "Migration can only be executed safely on 'postgresql'.");
        
        $this->addSql("DROP SEQUENCE acl_classes_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_security_identities_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_object_identities_id_seq1 CASCADE");
        $this->addSql("DROP SEQUENCE acl_entries_id_seq1 CASCADE");
    }

    public function down(Schema $schema)
    {
       
        $this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql", "Migration can only be executed safely on 'postgresql'.");
        
        $this->addSql("CREATE SEQUENCE acl_classes_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_security_identities_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_object_identities_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_entries_id_seq INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_classes_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_security_identities_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_object_identities_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
        $this->addSql("CREATE SEQUENCE acl_entries_id_seq1 INCREMENT BY 1 MINVALUE 1 START 1");
    }


 Comments   
Comment by Steve Müller [ 26/Oct/14 ]

Doctrine ORM 2.2.x is EOL and won't receive any updates anymore. Please consider upgrading to at least 2.3 and reopen if the issue is still there. There have been a LOT of fixes to platforms' SQL generation since 2.2.x.
Also if you still encounter the issue, please add your mapping information, otherwise it will be hard to rack the issue down.

Comment by Steve Müller [ 26/Oct/14 ]

Oh sorry read your ORM version constraint wrong. Reopening. Please can you give the exact DBAL version you are using and mapping information? Thanks.





[DBAL-662] Supporting PHP 5.5 DateTimeImmutable Created: 14/Nov/13  Updated: 02/Jul/14

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: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: mapping, schematool


 Description   

Introducing new types converting dates into a DateTimeImmutable rather than a DateTime could be useful for applications prefering the use of immutable datetimes (and relying on PHP 5.5+).

The existing types already support setting a DateTimeImmutable in a field mapped with the datetime type, as it does not check the value against DateTime but only expects a format method. but the conversion from DB to PHP wil