Doctrine Project

[DBAL-44] nullable is not working for all datatypes

Mon, 30 Aug 2010 05:22:25 +0000

The nullable=true annotation is ignored from at least following Types:

SmallIntType
DecimalType
BooleanType (not sure if nullable makes sense here)

[DBAL-37] auto increment can not be added to a column, when postgresql is used.

Sun, 25 Jul 2010 17:32:01 +0000

To add auto increment to on column using the following code in the
migration class:

$systemSettingsTable->changeColumn('setting_id',
array('autoincrement' => true));
or
$settingIdColumn = $systemSettingsTable->getColumn('setting_id');
$settingIdColumn->setAutoincrement(true);

This works fine when MySQL is used. But when PostGreSQL is used, this
statement doesn't create any SQL statement.

The patch in attachment could perhaps resolve this problem some way.

[DBAL-34] MySql getListTableForeignKeysSQL doesn't work for 5.0.xx

Mon, 15 Aug 2011 10:00:48 +0000

The sql contains mysql specific code. And for the mysql 5.0.xxx the sql statement has syntax error.

in /Doctrine/DBAL/Platforms/MySqlPlatform.php:
public function getListTableForeignKeysSQL($table, $database = null)
{
$sql = "SELECT DISTINCT k.`CONSTRAINT_NAME`, k.`COLUMN_NAME`, k.`REFERENCED_TABLE_NAME`, ".
"k.`REFERENCED_COLUMN_NAME` /*!50116 , c.update_rule, c.delete_rule */ ".
"FROM information_schema.key_column_usage k /*!50116 ".
"INNER JOIN information_schema.referential_constraints c ON ".
" c.constraint_name = k.constraint_name AND ".
" c.table_name = '$table' */ WHERE k.table_name = '$table'";

if ($database)

{ $sql .= " AND k.table_schema = '$database' AND c.constraint_schema = '$database'"; }

$sql .= " AND `REFERENCED_COLUMN_NAME` is not NULL";

return $sql;
}

For the mysql lower as 5.1.16 the SQL could be as the following:

SELECT DISTINCT k.`CONSTRAINT_NAME`, k.`COLUMN_NAME`, k.`REFERENCED_TABLE_NAME`, k.`REFERENCED_COLUMN_NAME` FROM information_schema.key_column_usage k WHERE k.table_name = 'some_table' AND k.table_schema = 'some database' AND c.constraint_schema = 'some database' AND `REFERENCED_COLUMN_NAME` is not NULL

In this statement there is no reference of c

[DBAL-33] Doctrine2 fails handling microseconds from PostgreSQL record

Sat, 24 Jul 2010 18:56:40 +0000

A column in database may be defined as both TIMESTAMP WITH TIMEZONE and TIMESTAMP WITHOUT TIMEZONE. If I insert a new value directly to the database through NOW() function, the value is stored including microseconds.

But then, when I am trying to load the record to Doctrine entity, following exception is thrown:

—

Doctrine\DBAL\Types\ConversionException

Could not convert database value "2010-07-17 15:29:57.762+02" to Doctrine Type datetimetz

File: C:\dev\etrener\library\Doctrine\DBAL\Types\ConversionException.php Line: 46

—

The same with both datetime and datetimetz columns.

The problem is probably in PostgreSqlPlatform::getDateTimeTzFormatString(), where is the following row:
public function getDateTimeTzFormatString()

{ return 'Y-m-d H:i:sO'; }

But PostgreSQL stores timestamps with microseconds, so format should be maybe something like:

{ return 'Y-m-d H:i:s.uO'; }

The problem is already posted in http://www.doctrine-project.org/jira/browse/DBAL-22?focusedCommentId=13574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_13574, but that issue is already closed so maybe it was overlooked already then.

Thank you for fix!

[DBAL-32] Ensure that error mode is EXCEPTION if existing PDO instance used

Wed, 7 Jul 2010 10:15:21 +0000

I am not sure whether we do that already but I remember having talked about it. It would probably be good to ensure that error mode is EXCEPTION if an existing PDO instance is used to create a DBAL Connection. Simply forcing the error mode by using setAttribute(PDO::ATTR_ERRMODE, PDO::ATTR_ERRMODE_EXCEPTION) should be sufficient.

[DBAL-30] Doctrine\DBAL\Connection::query() method does not connect automatically to the database

Wed, 30 Jun 2010 14:08:05 +0000

The database access methods in Doctrine\DBAL\Connection automatically connect to the database, if the connection has not been created yet. This is not true in case of Doctrine\DBAL\Connection::query() - if we forget to connect manually, we get:

Warning: call_user_func_array() expects parameter 1 to be a valid callback, first array member is not a valid class name or object in /.../Doctrine/DBAL/Connection.php on line 608

The problem is caused by the lack of

$this->connect();

line within the method body.

[DBAL-29] Comparator: Changing one column name and dropping one leads to changing both into the new name.

Wed, 30 Jun 2010 14:29:42 +0000

If you have a table and in a new version rename one and drop another column both of exactly the same definition, the comparator will errorusly optimize the one to rename both columns to the new one.

In these cases where it is not detectable which is the renamed and which the dropped it should drop both columns and create the new one. The user has to optimize this himself.

[DBAL-28] Better error messages while creating schema

Mon, 28 Jun 2010 16:45:43 +0000

I'd like to suggest some improvements in the schema builder concerning error messages, which do not tell the most important information needed to find the problem quickly and without irritation. Below, I present a simple case I encountered yesterday: I had a quite big schema to generate, but I made a mistake in index column names. Doctrine thrown me the following exception:

Doctrine\DBAL\Schema\SchemaException
An unknown column-name name was given.

What I miss, is the table name, where I try to define such an index. I took a look at the messages for SchemaException and I noticed that none of them provides it, except those ones which refer directly to tables.

Another small, but useful improvement is enclosing the table/column/index/sequence/anything-else names in quotes or double quotes in order to make them better distinguishable from the message body. My first impression from the message above was that I have a "column-name" name defined somewhere, not a column named "name".

To sum up, the expected message should look like this:

Doctrine\DBAL\Schema\SchemaException
An unknown column-name 'name' was given for index 'foo' in table 'bar'.

The problem is minor, but I would be grateful if you remembered about it in the near future, so that I could have more useful error messages at least in the stable releases.

[DBAL-26] DateTime type column can't be nullable

Sun, 27 Jun 2010 13:05:27 +0000

After upgrade from B1 to B2 my app stopped working, throwing ConversionException on nullable DateTime field, value of which is null.
There is part of DateTimeType.php which causes it - if (!$val) matches even the valid null value.

public function convertToPHPValue($value, AbstractPlatform $platform)
{
$val = ($value !== null)
? \DateTime::createFromFormat($platform->getDateTimeFormatString(), $value) : null;
if (!$val)

{ throw ConversionException::conversionFailed($value, $this->getName()); }

return $val;
}

[DBAL-22] Saving UTC Offset in Postgres DATETIME messes with PHP DateTime and Timezones

Tue, 13 Jul 2010 07:42:05 +0000

The DateTime type is currently unusable in PostgreSQL due to a wrong parsing format.

PostgreSqlPlatform::getDateTimeFormatString() should be changed from:

Y-m-d H:i:sO

Y-m-d H:i:s.uO

According to http://twitter.com/auroraeosrose/statuses/16154268629

Also, there's no way to check if a convert From and To PHP/Database worked correctly. Maybe we should introduce an exception when a DBAL\Type conversion fails, otherwise, there's no way to figure it out what happened.

[DBAL-21] Pgsql: getListTableColumnsSQL: read domains info (patch provided)

Sun, 20 Jun 2010 09:05:04 +0000

Hello,

If you use DOMAIN (CREATE DOMAIN) in pgsql, PostgreSqlPlatform generate a "new \Doctrine\DBAL\DBALException("Unknown database type ".$dbType." requested, " . get_class($this) . " may not support it.");" exception because it does not know the type "domain_name" (CREATE DOMAIN domain_name AS VARCHAR(80); )

With this patch, it checks if the given type (either normal type, either domain) is a domain, and if yes, takes the right info (domain_name is type varchar and complete_type character varying(80)). If it's not a domain, it takes the normal type.

(patch -p0 doctrine2/lib/Doctrine/DBAL/Platforms/PostgreSqlPlatform.php < pgsql_domains.patch)

Also, it's not the goal here, but the queries could be optimized using joins in place of auto join + where, but, as said, the speed is not the goal since the queries are there only for entities mapping.

Hope it helps.

Best regards,

Raphaël Dehousse

[DBAL-17] E_STRICT error in Doctrine\DBAL\Driver\OCI8\Driver::_constructDsn()

Mon, 28 Jun 2010 16:51:04 +0000

I get an E_STRICT error in Doctrine\DBAL\Driver\OCI8\Driver::_constructDsn() because I forgot to set a 'dbname' key in the params array to Doctrine\DBAL\DriverManager.

My Doctrine is a svn checkout, from 2.0.0-beta1 tag.

A patch is attached (patch -p0 < patch.diff on project root).

[DBAL-11] Improve API of Sqllogger

Sun, 20 Jun 2010 10:52:27 +0000

The SqlLogger currently has a very simple API, which lacks for example the possibilty to log the execution time of queries. This would require a second call of the logger however, but i made some performance tests on the current implementation. Its using the following check to look if logging is enabled:

if($this->_config->getSqlLogger())

However:

if($this->_hasLogger)

Only takes half the time. See the test at the bottom.

We could switch to a boolean flag and use the "saved" time to enhance the SQL Logger API to include the following information:

1. SQL (Have already)
2. Params (Have already)
3. Elapsed Time (Start Time and End Time)
4. Query Type (SELECT, INSERT, UPDATE, DELETE, OTHER)

This would benefit both Symfony and ZF since they could hook into the logger for their respective debugging facilities (sf Web Toolbar, Zend Firebug SQL Profiling).

<?php                                                                                             
class Config                                                                                      
{                                                                                                 
    protected $_logger;                                                                           
    public function __construct()                                                                 
    {                                                                                             
        $this->_logger = new stdClass();
    }
    public function getLogger()
    {
        return $this->_logger;
    }
}

class Foo
{
    protected $_config = null;
    public function __construct()
    {
         $this->_config = new Config();
    }
    public function execute()
    {
         if($this->_config->getLogger()) {
         }
    }
}

class Bar
{
    protected $_config = null;
    protected $_loggerExists = false;
    public function __construct()
    {
         $this->_config = new stdClass();
         $this->_loggerExists = true;
    }
    public function execute()
    {
        if($this->_loggerExists) {

        }
    }
}

$f = new Foo();
$s = microtime(true);
for($i = 0; $i < 100; $i++) {
    $f->execute();
}
echo (microtime(true)-$s)."s\n";

$f = new Bar();
$s = microtime(true);
for($i = 0; $i < 100; $i++) {
    $f->execute();
}
echo (microtime(true)-$s)."s\n"

benny@benny-pc:~/code/php/wsnetbeans/Doctrine/trunk/tests$ php /tmp/boolvsmethod.php                
0.00055313110351562s                                                                                  
0.00025200843811035s                                                                                  
benny@benny-pc:~/code/php/wsnetbeans/Doctrine/trunk/tests$ php /tmp/boolvsmethod.php                
0.00051999092102051s                                                                                
0.00025200843811035s                                                                                
benny@benny-pc:~/code/php/wsnetbeans/Doctrine/trunk/tests$ php /tmp/boolvsmethod.php                
0.00036001205444336s                                                                                
0.00017309188842773s                                                                                
benny@benny-pc:~/code/php/wsnetbeans/Doctrine/trunk/tests$ php /tmp/boolvsmethod.php                
0.0005180835723877s                                                                                 
0.00025010108947754s

[DBAL-2] Schema Comparator - Changes of only Identifier Strategy are not detected

Duplicate — Sun, 13 Jun 2010 14:24:48 +0000

When changing metdata from a NONE to an IDENTITY generator only for example on MySQL, SchemaComparator does not pick up the changes.