Doctrine Project

[DC-207] Masked exception makes it very difficult to debug

Tue, 10 Nov 2009 16:34:31 +0000

When you try to save an object, but the database does not exist, Doctrine throws a Doctrine_Transaction_Exception exception with the message "Rollback failed. There is no active transaction.".

But the real problem is that the database does not exit. The problem is in the Doctrine_Connection_UnitOfWork class around line 146:

        } catch (Exception $e) {
            // Make sure we roll back our internal transaction
            //$record->state($state);
            $conn->rollback();
            throw $e;
        }

The exception occurs because of "$conn->rollback();", and so the "throw $e;" is never reached.

We should probably throws an exception earlier about the fact that the database does not exist.

[DC-205] Problem with serial fields on PostgreSQL

Tue, 10 Nov 2009 16:18:03 +0000

When a new record is inserted into a table with an autoincrement primary key, the function Doctrine_Connection_UnitOfWork::processSingleInsert is called with the record to insert as parameter.

In Doctrine 1.1.x (http://trac.doctrine-project.org/browser/branches/1.1/lib/Doctrine/Connection/UnitOfWork.php#L590) this method was the responsible for getting the new ID value from the sequence, and with this value, it MODIFIED THE ARRAY OF FIELD VALUES to be inserted into the table.

Now this is done at a protected method named _assignSequence (http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/Connection/UnitOfWork.php#L629) which assigns the identifier to the record, but DOES NOT MODIFY THE ARRAY OF VALUES to be send to the database for the insert so when my db receive a null value for the ID column, generate a new one from the sequence.

The result is that the record gets an identifier which is different from the one that it really has on the database.

An example: on a db with a table 'foo' with two columns, 'id' and 'name', and a sequence called 'foo_id_seq' with a value of 6, when I try to insert a record with a named 'bar', the function $this->conn->insert($table, $fields); at http://trac.doctrine-project.org/browser/branches/1.1/lib/Doctrine/Connection/UnitOfWork.php#L595 receive as parameters 'foo' and array('id' =>7, 'name' =>'bar')

In Doctrine 1.2 the function at http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/Connection/UnitOfWork.php#L630 recevie as parameters 'foo' and array('name' =>'bar')

(Sorry for my poor English)

[DC-204] [patch] Cloning or copying a query object keeps a reference to the previous hydrator

Tue, 10 Nov 2009 16:56:43 +0000

Upon cloning or copying a query object, the hydrator property still points to the original query. Changing it in the child object changes it for the parent object.

thanks to gnat42 for the patch

[DC-201] [PATCH] Level is oracle keyword (reopened #479)

Tue, 10 Nov 2009 17:01:46 +0000

I created this ticket in connection to the http://trac.doctrine-project.org/ticket/479

The resolution was that it's fixed in http://trac.doctrine-project.org/changeset/3183/ - but it seems that it is fixed only in the changelog.

The LEVEL is an oracle keyword and the only way to use the NestedSet with Oracle is enabled quote identifiers.
We used this for about a year or more, but it is not so comfortable and this is the only reason why we are quoting identifiers.

But we started to use Oracle's spatial features and I was surprised that some oracle spatial functions are not able to work on quoted objects, and I started to use synonyms and extra columns with triggers as workaround. But it is so annoying and the patch is so simple

[DC-197] [patch] default model orderBy option breaks data-load task

Tue, 10 Nov 2009 17:52:42 +0000

currently the default orderBy clause one can specify for models gets added to all queries, including DELETE and UPDATE.
This breaks data-load because it includes in the orderBy the table alias but currently only SELECT queries support aliases.

For example if I have the following schema:

Mytable:
options:

{ orderBy: name ASC }

columns:
name:

{ type: string(100), notnull: true }

The data-load task does a Doctrine::getTable('Mytable')~~>delete()~~>execute(); to clear the table before loading the fixtures which results in the following SQL:
DELETE FROM mytable ORDER BY m.name ASC

which errors out as the m alias was not defined.

Attached is the patch that makes only SELECT queries get the default orderBy clause from the option.

[DC-192] Doctrine_Import_Builder Missing Relation Alias When Using classPrefix

Tue, 10 Nov 2009 17:58:08 +0000

Doctrine_Import_Builder, line 383

$alias = (isset($relation['alias']) && $relation['alias'] !== $relation['class']) ? ' as ' . $relation['alias'] : '';

For example, if both class name and alias is "User" and we make use of classPrefix (i.e "Model_"), the generated class name will actually be "Model_User". The comparison of:

$relation['alias'] !== $relation['class']

does not cover the prefix, which lead to the missing of alias when generating models, i.e

$this->hasOne('Model_User', ...

instead of

$this->hasOne('Model_User as User', ...

Suggested fix:

$alias = (isset($relation['alias']) && $relation['alias'] !== $this->_classPrefix . $relation['class']) ? ' as ' . $relation['alias'] : '';

[DC-191] Doctrine_Migration->loadMigrationClassesFromDirectory fail when launched 2 times

Tue, 10 Nov 2009 17:19:08 +0000

When I need to create a Doctrine_Migration twice during a same php processus, the migrations version numbers get wrong.

In Doctrine_Migration->loadMigrationClassesFromDirectory method, I see :

        if (isset(self::$_migrationClassesForDirectories[$directory])) {
            $migrationClasses = (array) self::$_migrationClassesForDirectories[$directory];
            $this->_migrationClasses = array_merge($migrationClasses, $this->_migrationClasses);
        }

The problem is that array_merge loose the array keys. In the $this->_migrationClasses context, array keys are very important because they are the version numbers.

So when if (isset(self::$_migrationClassesForDirectories[$directory])) is true ( ie the second time we use the Doctrine_Migration classs ) all the migrations versions get wrong.

I hope my description is clear enough.

[DC-190] Fatal error while connecting after an reset of the Doctrine_Manager

Tue, 10 Nov 2009 17:29:49 +0000

Doctrine_Manager::connection('sqlite::memory:');
Doctrine_Manager::resetInstance();
Doctrine_Manager::connection('sqlite::memory:');
Fatal error: Call to a member function onOpen() on a non-object in ...../Doctrine/Connection.php on line 221

which is $this->getAttribute(Doctrine_Core::ATTR_LISTENER)->onOpen($this);

The Doctrine_Core::ATTR_LISTENER attribute is not set in the connection nore in the manager... This is because Doctrine_Manager::resetInstance does remove all attributes but Doctrine_Manager::setDefaultAttributes does not allow to set the default attributes twice.

This method can only run once, because it use a local static $init variable and since Doctrine_Manager is a Singleton the init value should stored within the instance.

What happens :
1. In Doctrine_Manager::setDefaultAttributes() the Doctrine_Core::ATTR_LISTENER is set to new Doctrine_EventListener().
2. A connection get its attributes from the manager when not available in the connection.
3. When Doctrine_Manager::reset() is called the attributes are gone and should be set again...
4. However because the Doctrine_Manager::setDefaultAttibutes method only can run once (a check is set in a static local boolean) the listener is not recreated and thus subsequent connections will fatally fail

patch by
A fix is simple and I have it running locally...

1. add an private $_inited or $_defaultAttributesSet property to Doctrine_Manager, defaults to false;
2. on Doctrine_Manager::reset reset it to its default (false)
3. on Doctrine_Manager::setDefaultAttibutes do nothing when the property equals true, but when the property is false proceed with setting the default attributes...

[DC-186] Patch to correct CLI tests

Wed, 4 Nov 2009 20:20:26 +0000

Enclosed is a little patch to correct my CLI tests.

The patch wraps test runs on the CLI in an output buffer to prevent output to the console when the unit tests are run. This output from the CLI could be mistaken for errors, but it's expected and only looks unfriendly - no errors / exceptions are thrown.

[DC-184] Doctrine_Connection_Statement->execute() gerenates a PHP warning with Doctrine 1.2 BETA1

Wed, 4 Nov 2009 19:42:22 +0000

// switch between 1.2 ALPHA3 and 1.2 BETA1
//require_once('../CMS/Doctrine-1.2.0-ALPHA3-Sandbox/lib/Doctrine.php');
require_once('../CMS/Doctrine-1.2.0-BETA1-Sandbox/lib/Doctrine.php');

spl_autoload_register(array('Doctrine', 'autoload'));
$manager = Doctrine_Manager::getInstance();
$conn = Doctrine_Manager::connection('mysql://user:password@localhost/test');

// table creation (done with Doctrine 1.2 ALPHA3)
//$conn->export->createTable('test', array('name' => array('type' => 'string')));
//$conn->execute('INSERT INTO test (name) VALUES (?)', array('vince'));

// retreive data from table
$stmt = $conn->prepare('SELECT * FROM test');
$stmt->execute();
$results = $stmt->fetchAll();
var_dump($results);

In the code above, $stmt->execute(); generates a warning (but the data is retreived from the table) under 1.2 BETA1 (no problem with 1.2 ALPHA3) :

Warning: Invalid argument supplied for foreach() in F:\Vince\devweb\CMS\Doctrine-1.2.0-BETA1-Sandbox\lib\Doctrine\Connection\Statement.php on line 245
Line 245 is part of a block of code added in lib/Connection/Statement.php (execute function) in 1.2 BETA1 :

$pos = 0;
 foreach ($params as $key => $value) {
    $pos++;
    $param = is_numeric($key) ?  $pos : $key;
    if (is_resource($value)) {
        $this->_stmt->bindParam($param, $params[$key], Doctrine_Core::PARAM_LOB);
    } else {
        $this->_stmt->bindParam($param, $params[$key]);
    }
}

The call stack from xdebug shows the function : Doctrine_Connection_Statement->execute()

I see the warning because of my php.ini settings : error_reporting = E_ALL
I mention this issue because sometimes a warnig may result in a more important error later in the code.

[DC-180] [PATCH] Unique index name for column aggregation key column

Wed, 4 Nov 2009 19:45:34 +0000

When using column aggregation colum with the same name on multiple models, and exporting schema to database, I have a collisions with names in Oracle (I think others are affected too).

{{
CREATE INDEX "type" ON "nt_organism_property" ("type")
CREATE INDEX "type" ON "nt_property" ("type")
CREATE INDEX "type" ON "st_node" ("type")
}}

I propose to prefix the index name with the table name

[DC-179] Wrong length estimation in Doctrine_Validator->validateLength() if locale sets decimal point other than "dot"

Wed, 4 Nov 2009 19:50:15 +0000

Test case:
1) set locale: setlocale(LC_ALL, "") (on windows it sets current international control panel settings), in case of Polish locale it changes decimal point to ',' (comma)
2) try to save value "12,12" of decimal type field (mysql type):

{ type: decimal(4), scale: 2 }

,
3) it gives you validation error (length)

Summary:
Doctrine_Validator->validateLength() could not count length properly.

Idea:
I changed dot character in explode function to proper env character:

// changes start
$localeInfo = localeconv();
$e = explode($localeInfo["mon_decimal_point"], $value);
// changes end

It works for me.

Enclosed Validator.php

[DC-178] Import Builder doesn't use default table class name

Wed, 4 Nov 2009 19:52:49 +0000

I use Symfony 1.2.9 with Doctrine 1.2 trunk.

I also make use of the new Doctrine's feature to specify custom table class. For that, in the config/ProjectConfiguration.class.php I have the following code:

   public function configureDoctrine(Doctrine_Manager $manager)
   {
      ...
      $manager->setAttribute(Doctrine::ATTR_TABLE_CLASS, 'Platform_DoctrineTable');
      ...
   }

And that works fine. But when I comment out this line and re-generate model classes, I get broken table class definitions like:

class AccountTable extends 
{

}

Notice the lack of base class name.

It seems the problem resides in Doctrine_Import_Builder's constructor:

    public function __construct()
    {
        $this->_baseTableClassName = Doctrine_Manager::getInstance()->getAttribute(Doctrine_Core::ATTR_TABLE_CLASS);
        $this->loadTemplate();
    }

So, the default value of $this->_baseTableClassName always overwrites by Doctrine_Core::ATTR_TABLE_CLASS attribute value.

[DC-156] missing foreignType: one in code example if "Foreign Key Associations" in chapter "Defining Models"

Tue, 10 Nov 2009 17:40:48 +0000

in the code example for "One-to-one" relation, the "one-to-one" relation is built by extending the BaseUser instead of adding 'foreignType' => 'one' to the setUp.

if done this way, the next Tip and Note have to be rewritten, and the next code example becomes unnecessary.

an attempt at it is attached.