[DBAL-212] Unknown database type longvarchar requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it. Created: 28/Jan/12  Updated: 28/Jan/12  Resolved: 28/Jan/12

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

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


 Description   

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.



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

Fixed





[DBAL-211] wrong where clause in PostgreSqlPlatform::getTableWhereClause Created: 26/Jan/12  Updated: 28/Jan/12  Resolved: 28/Jan/12

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

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

ubuntu + postgres



 Description   

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)



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

This looks very good.

Comment by Benjamin Eberlei [ 28/Jan/12 ]

Fixed





[DBAL-206] OraclePlatform causes problems with more schemas with same table names Created: 20/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

Type: Bug Priority: Minor
Reporter: Fran Pregernik Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Oracle database



 Description   

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.



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

Fixed.





[DBAL-205] MySQL SchemaManager doesn't handle composite foreign keys properly Created: 19/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

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


 Description   

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-201] Remote IBM DB2 connection needs protocol specified Created: 13/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

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

Type: Bug Priority: Minor
Reporter: Suzy Deffeyes Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

using doctrine2 included in symfony2 2.0.9, running on MAMP on OSX



 Description   

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.



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

This is primarily a DoctrineBundle bug. However i fixed it in DBAL to default to TCPIP protocol parameter now.

DB2 is not "really" supported. I have considerable problems with it segfaulting the DBAL testsuite. You should be very careful.





[DBAL-195] Method AbstractSchemaManager->dropAndCreateSequence() contains erroneous code. Created: 06/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

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

Attachments: Text File AbstractSchemaManager_dropAndCreateSequence.patch    

 Description   

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 )



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

Oh the code worked before, but was refactored. This method was forgotten.

Comment by Benjamin Eberlei [ 09/Jan/12 ]

Fixed.





[DBAL-190] Column type comment SQL is missing during table creation Created: 23/Dec/11  Updated: 03/Jan/12  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: 2.1.6, 2.2-BETA2, 2.2
Security Level: All

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Latest DBAL master



 Description   

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



 Comments   
Comment by Benjamin Eberlei [ 23/Dec/11 ]

This issue is referenced in Github Pull-Request GH-84
https://github.com/doctrine/dbal/pull/84

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/dbal/pull/84

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Fixed





[DBAL-184] bigint binding problems in sqlite3 Created: 28/Nov/11  Updated: 11/Dec/11  Resolved: 11/Dec/11

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

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

CentOS 4, PHP 5.3.8, Doctrine 2.1.4



 Description   

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



 Comments   
Comment by Benjamin Eberlei [ 11/Dec/11 ]

Fixed





[DBAL-146] Mssql platform TOP and DISTINCT ordering issue Created: 10/Aug/11  Updated: 09/Jan/12  Resolved: 09/Jan/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1
Fix Version/s: 2.1.6, 2.2

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

Windows 2008 R2 SqlSrv 2008 R2 IIS 7.5, fully patched


Attachments: Text File FixDisctinctTopOrderingIssue.patch    

 Description   

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.



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

Fixed





Generated at Wed Jul 30 11:30:02 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.