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





Generated at Sun Aug 30 08:02:10 EDT 2015 using JIRA 6.4.10#64025-sha1:5b8b74079161cd76a20ab66dda52747ee6701bd6.