[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 |
||
| 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] 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: Can anyone confirm this issue? Greetings, |
| 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: |
|
| 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 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 |
||
| Attachments: |
|
| Description |
|
I have a column in an entity, defined as "float" type. 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'. '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. |