[DBAL-157] Exception given when updating schema Created: 22/Aug/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

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

Type: Bug Priority: Minor
Reporter: Chris Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

Mac OSX 10.6.7
PHP 5.3.4



 Description   

Been experimenting with Symfony2 past days, and somehow managed to generate an Exception in the MySqlSchemaManager Classes of Doctrine.

I've build my schema once, the next time i run the command i'm receiving following error:

[ErrorException]
Notice: Undefined index: default in /Users/chris/Sites/Symfony/vendor/doctrine-dbal/lib/Doctrine/DBAL/Schema/MySqlSchemaManager.php line 157

i can't figure out an error in my classes.

When i drop the database table, i can re-run the command again without exception.. even though another run it will throw it up again.

I've checked the code in line #157, and adpted it slightls:

prev:

'default' => $tableColumn['default'],

modified:
'default' => (isset($tableColumn['default'])) ? $tableColumn['default'] : null,

Can anyone confirm this issue?

Greetings,
Chris



 Comments   
Comment by Chris K [ 25/Sep/11 ]

Hi, I'm also seeing this exact issue using Sf2 and Doctrine. You can't use the console to force update the schema, you have to completely drop all of the tables to get the command to work again. Also using Mac locally.

Comment by Benjamin Eberlei [ 18/Nov/11 ]

Interesting that some MySQL versions dont seem to have the default field then in information_schema?

Comment by Benjamin Eberlei [ 18/Nov/11 ]

Fixed, will be in 2.1.4





[DBAL-171] PARAM_INT_ARRAY / PARAM_STR_ARRAY depends of parameter order Created: 11/Sep/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

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

Type: Bug Priority: Major
Reporter: arnaud-lb Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

Named parameters appears to be treated as ordered parameters, when using PARAM_INT_ARRAY or PARAM_STR_ARRAY:

$query = $em->createQuery('
SELECT f FROM Foo f
WHERE a = :a
AND b IN (:b)
');

$query->setParameters(array(
    'b' => array(1,2,3),
    'a' => 1,
));

Notice that in the query the parameter :a appears before :b. And I call ->setParameters() with :b before :a.

When running this, I get an error from Doctrine/DBAL/SQLParserUtils::expandListParameters:119 saying that the second parameter of array_merge() is not an array.

When setting the parameters in the same order than they appear in the query, it works:

$query->setParameters(array(
    'a' => 1,
    'b' => array(1,2,3),
));

This is unexpected, as I'm using named parameters; the order should not matter.



 Comments   
Comment by Patrick Schwisow [ 27/Sep/11 ]

I'm getting this issue too.

Doctrine\ORM\Query::_doExecute() does a ksort on $sqlParams, but does not sort $types. Doctrine\DBAL\SQLParserUtils::expandListParameters() assumes that $params and $types are in the same order.

As a workaround, I added ksort($types) in _doExecute(), but I'm not sure if this is the proper way to handle this.

Comment by Benjamin Eberlei [ 18/Nov/11 ]

Fixed





[DBAL-144] Oracle tables without indices are not handled during convert - this behavior should be tolerant since Oracle does not require indicies. Created: 02/Aug/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1
Fix Version/s: 2.1.5

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

CentOS 5.0, PHP 5.3.6, Oracle 11g EE, Symfony 2.0 Doctrine 2.1



 Description   

While it is good practice to always have at least one index defined on every table, in some cases (such as temporary tables) indices are not necessary. Oracle does not enforce creating indices for every table, and it is common to create some tables without them. The Table.php (line 556) method throws an exception if an index is not found for a given table. It's obvious there are ramifications for findByPK( ) auto-generated methods - these should be generated for every case where PK exists to accommodate Oracle and tolerate variances from accepted best-practices with most other database platforms.



 Comments   
Comment by Benjamin Eberlei [ 30/Oct/11 ]

When does this error happen?

This method is called through Table::getPrimaryKey(). Does this happen during the "doctrine:schema*" toolchain?

Comment by Ed Anderson [ 30/Oct/11 ]

This happens in the doctrine:schema toolchain.

Comment by Benjamin Eberlei [ 14/Nov/11 ]

Fixed.





[DBAL-181] [Oracle] RAW Type Created: 14/Nov/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

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

Linux 64bits 2.6.35-30, Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 64bits


Attachments: Text File raw.patch    

 Description   

Missing type raw from OraclePlatform::initializeDoctrineTypeMappings.

The Symfony2 task doctrine:schema:update throws Unknown database type raw requested, Doctrine\DBAL\Platforms\OraclePlatform may not support it..

The attached patch seems to fix it, but I don't know if something more to be done.



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

Is raw really a text? Is it similar to VARBINARY or something?

Comment by Benjamin Eberlei [ 14/Nov/11 ]

Fixed.

Comment by Juan M [ 14/Nov/11 ]

Thank you Benjamin. Sorry I didn't answer before.

I don't use RAW type in my tables, but Oracle creates tables when you do an export/import that contains this type. This tables starts with "SYS_" and must be ignored. I'm not an expert, but maybe change the list tables method to another that doesn't return the system tables.

Either way, this works perfect. Thanks again.





[DBAL-168] orm:schema-tool:update will fail if if public scheme has a domains table (PostgreSQL) Created: 22/Sep/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

Type: Bug Priority: Critical
Reporter: Martin Prebio Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

If I create a table 'domains' in the default scheme and execute the update procedure of the schema tool, it will throw a PDOException (SQLSTATE[21000]: Cardinality violation: 7 ERROR: more than one row returned by a subquery used as an expression)

I've traced the error to the following statement, which is created by Doctrine\DBAL\Platforms\PostgreSqlPlatform->getListTableForeignKeysSQL():

SELECT r.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 c.relname = 'domains'
                        AND n.oid = c.relnamespace
                  )
                  AND r.contype = 'f'

This returns two oids because there are two relations with the name domains. One is my table and the other is a view in the information_scheme scheme.

The same problem should occur with the other information_scheme relations.



 Comments   
Comment by Benjamin Eberlei [ 30/Oct/11 ]

Hm the domains entry doesnt seems to pop up for me in pgadmin when executing your query. Can you help me a bit with details on how to reproduce this?

Comment by Martin Prebio [ 31/Oct/11 ]

montbook:~ postgres$ createdb -E UTF8 -T template0 -l de_AT.UTF-8 foo
montbook:~ postgres$ psql foo
foo=# create table domains (id int8 not null);

Now I have a table domains in the default schema and a domains table in the information_schema schema which is created and maintained by postgres. Now executing the query above will produce the mentioned exception.

It was necessary to create a table in the fresh database to create the information_schema. It is a meta schema from where you can select information of the database and it is afaik a sql standard (also mysql has it but as a seperate database).

pgAdmin may hide this schema (and the pg_catalog): http://www.mail-archive.com/pgadmin-support@postgresql.org/msg09332.html

Comment by Benjamin Eberlei [ 14/Nov/11 ]

Fixed and merged into 2.1.x





[DBAL-158] Sqlite Platform doesn't set a proper mapping for "double precision" to act as float. Created: 24/Aug/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.1
Fix Version/s: 2.1.5

Type: Bug Priority: Major
Reporter: Doron Gutman Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

Ubuntu Linux 11.04
PHP 5.3.5


Attachments: Text File 0001-Fix-for-DBAL-158-where-double-precision-was-not-work.patch    

 Description   

I have a column in an entity, defined as "float" type.
When I run my phpunit tests (which are defined to use sqlite, whereas my production and development environment uses mysql), I get the following exception:

Doctrine\DBAL\DBALException: Unknown database type double precision requested, Doctrine\DBAL\Platforms\SqlitePlatform may not support it

Looking at AbstractPlatform.php, line 1972, function "getFloatDeclarationSQL" returns 'DOUBLE PRECISION'.
Where other platforms have in their "initializeDoctrineTypeMappings" method a mapping such as:

'double precision' => 'float',

, SqlitePlatform.php doesn't have such a mapping.



 Comments   
Comment by Steven Rosato [ 11/Oct/11 ]

I have encountered the same issue while using sqlite. I have made a simple fix in the platform class, as seen in the patch I provided which hopefully fixes the issue.

Comment by Benjamin Eberlei [ 30/Oct/11 ]

Was fixed





[DBAL-172] QueryBuilder joins are omitted if the table alias is not present in the "from" clause Created: 26/Sep/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

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

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

MySQL



 Description   

When using the QueryBuilder, joins that refer to table aliases from other joins get omitted. Only those joins that refer to table aliases from the "from" clause get included.

See http://stackoverflow.com/questions/7331117/doctrines-dbal-query-builder-omitts-some-joins



 Comments   
Comment by Anush Ramani [ 27/Sep/11 ]

Just realized that there is a way to solve the issue with omitted joins. Essentially, we'd always need to use one of the FROM table aliases as the $fromAlias for the join() methods. While this works quite well, it seems un-intuitive.

If this is expected behavior, I can close the ticket, but again, seems a bit un-intuitive.

Comment by Benjamin Eberlei [ 30/Oct/11 ]

fixed.

An exception is now thrown when this occurs with details on how to fix it.





Generated at Thu Apr 24 13:53:34 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.