Doctrine Project

[DBAL-211] wrong where clause in PostgreSqlPlatform::getTableWhereClause

Sat, 28 Jan 2012 09:55:23 +0000

I have the folowing table structure:

Schema "public": with one table called "users"
Schema "forums": with one table called "users"

methods like PostgreSqlPlatform::getListTableForeignKeysSQL($table, $database = '') should list FK inside $table

the default search path is "public,pg_catalog"

calling PostgreSqlPlatform::getListTableForeignKeysSQL('users') it shuld extract the FK from public.users table, but this is the current result:

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

this exception is thrown because PostgreSqlPlatform::getTableWhereClause do not cosider the current search path.

i propose the following implementation for PostgreSqlPlatform::getTableWhereClause

 
    private function getTableWhereClause($table, $classAlias = 'c', $namespaceAlias = 'n')
    {
        $whereClause = $namespaceAlias.".nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast') AND ";
        if (strpos($table, ".") !== false) {
            list($schema, $table) = explode(".", $table);
            $whereClause .= "$classAlias.relname = '" . $table . "' AND $namespaceAlias.nspname = '" . $schema . "'";
        } else {
            // $whereClause .= "$classAlias.relname = '" . $table . "'"; // this was the current implementation
            $whereClause .= "$classAlias.relname = '" . $table . "' AND $namespaceAlias.nspname = ANY(string_to_array((select setting from pg_catalog.pg_settings where name = 'search_path'),','))";
        }

        return $whereClause;
    }

this implementation will restrict the search range only to current "search_path".

(sorry for my english)

[DBAL-212] Unknown database type longvarchar requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it.

Sat, 28 Jan 2012 09:31:53 +0000

SqlitePlatform lacks "longvarchar" type mapping which is extensively used by browsers sqlite databases (e.g. places in FF, history in Chrome).
Trying to get a schema ends up with 'Unknown database type longvarchar requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it.' message.

[DBAL-205] MySQL SchemaManager doesn't handle composite foreign keys properly

Sat, 21 Jan 2012 15:18:28 +0000

The MySQL SchemaManager can not properly generate a Schema from the database if a table has a foreign key that spans multiple columns.
Therefore the comparator tries to drop the one index as individual indexes.

That leads to an error if the resulting SQL is executed because these indexes do not exist (i.e. via app/console doctrine:schema:update --force)

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

...
ALTER TABLE table1 DROP FOREIGN KEY FK_C1B1712387FE737264DE5A5511B8B3E;
DROP INDEX IDX_C1B1712387FE7372 ON table1;
DROP INDEX IDX_C1B1712364DE5A5 ON table1;
DROP INDEX IDX_C1B17123511B8B3E ON table1;
ALTER TABLE table1 ADD CONSTRAINT FK_C1B1712387FE737264DE5A5511B8B3E FOREIGN KEY (column1, column2, column3) REFERENCES table2(column1, column2, column3);
...

[DBAL-206] OraclePlatform causes problems with more schemas with same table names

Sat, 21 Jan 2012 14:11:54 +0000

OraclePlatform is using the ALL_* tables to fetch schema information but is only supplying the table name in the where condition. This causes problems when you have multiple schemas with tables that have the same name. Their columns/FK get mixed up.

My colleague and I have traced the problem down to the OraclePlatform class and replaced the ALL_* tables with USER_*. The fix for that is on github https://github.com/FranPregernik/dbal/commit/c70bc462b49a168105304cdff0086dcd15cc347d.

As mentioned in the comment message the other fix would be to fetch the schema name (user) of the table and add it to the where part of the queries. Something like this:

t.owner = user

A pull request has been made on github for this.

[DBAL-201] Remote IBM DB2 connection needs protocol specified

Sat, 21 Jan 2012 13:47:39 +0000

Thanks so much for adding DB2 support to Doctrine2, it's awesome!

I'm using it to connect to a remote DB2 database, and in db2driver.php, it is expecting the 'protocol' parameter to be set. I tried the obvious, adding a database_protocol to my parameters.ini file (to match the other database things in there), but that didn't work.

I did a temporary fix of hardcoding it in the db2driver.php to be PROTOCOL=TCPIP , and it works.

So i think the proper fix would be to add the code so that database_protocol in parameters.ini is picked up.

[DBAL-146] Mssql platform TOP and DISTINCT ordering issue

Mon, 9 Jan 2012 13:30:27 +0000

When doing a limit and a distinct query, DBAL generates an SQL statement in the form of SELECT TOP X DISTINCT, which SqlSrv does not like at all. Simply moving the the DISTINCT back to the start fixes this issue.

As far as I can see this is caused by the preg_replace in doModifyLimitQuery. Attached is a patch that makes it slightly more aware. There may be other phrases to check for, but none that I've come across yet.

Patch attached.

[DBAL-195] Method AbstractSchemaManager->dropAndCreateSequence() contains erroneous code.

Mon, 9 Jan 2012 07:57:39 +0000

I needed to use the function and looking at the code I found that it seemed partially implemented, cut and pasted from something else or just not ported from an earlier implementation. I'm now submitting a patch that fixes this issue. I didn't modify the AbstractSchemaManager->dropSequence($name) signature to become AbstractSchemaManager->dropSequence($sequence) but it might be a good idea to refactor it (guess that would be another issue though )

[DBAL-190] Column type comment SQL is missing during table creation

Tue, 3 Jan 2012 22:04:19 +0000

Column type comment is generated properly only with MySQL, and is not generated on platforms that support comment on column statements (Oracle, PgSQL).

[DBAL-184] bigint binding problems in sqlite3

Sun, 11 Dec 2011 15:49:33 +0000

I created a @Column that was type "bigint" and when inserting very large numbers, they were getting capped in SQLite3 at 2147483647.

I switched Doctrine/DBAL/Types/BigIntType.php, line 46 from:

return \PDO::PARAM_INT;

to:

return \PDO::PARAM_STR;

and now it is storing the full numbers. I am unsure, however, whether this is the right change or will affect other database layers. Any thoughts?

Matt