Doctrine Project

[DC-175] New hardDelete() on Soft Delete Template creates blank records

Tue, 3 Nov 2009 17:00:18 +0000

When using the new hardDelete() in the SoftDelete template, the postDelete() listener is saving a blank record because it calls ->save() on the record, even if the record was hard deleted.

    public function postDelete(Doctrine_Event $event)
    {
      $event->getInvoker()->save();
    }

should be

 
    public function postDelete(Doctrine_Event $event)
    {
      if ( ! $this->_options['hardDelete']) {
        $event->getInvoker()->save();
      }
    }

[DC-173] Error generating models from db when a table name is a reserved word in PostgreSQL

Fri, 27 Nov 2009 18:02:33 +0000

I'm getting an exception when generating models from db because I have a table named 'role' which is a reserved word, as you can see at http://www.postgresql.org/docs/8.1/static/sql-keywords-appendix.html

I have a table named 'role_permission' which has a foreign key pointing to table 'role'. When Doctrine tries to find the related tables using 'Doctrine_Import_Pgsql::listTableRelations()', the executed SQL returns:
FOREIGN KEY (role_id) REFERENCES "role"(role_id) ON DELETE CASCADE
with the table name role quoted as it is a reserved word.

My workaround is to change Doctrine_Import_Pgsql line 281 from:

$relations[] = array('table' => $values[2],

to:

$relations[] = array('table' => (strpos($values[2],'"') === 0)?substr($values[2],1,-1):$values[2],

[DC-172] change 6611 wrong

Mon, 2 Nov 2009 20:50:56 +0000

see line 95 in branches/1.2/lib/Doctrine/Connection/UnitOfWork.php

if ($ids) {
$record->unlinkInDb($alias, array());
} else if ($ids) {
$record->unlinkInDb($alias, array_keys($ids));
}

[DC-171] make it possible to force deletion when using softdelete

Tue, 3 Nov 2009 03:52:06 +0000

it would be nice to be able to force deleting when using softdelete. right now it seems like there is no way to still be able to do a real DELETE.
http://www.doctrine-project.org/documentation/manual/1_1/en/behaviors:core-behaviors:softdelete

something like $record->delete(true);

take for example some undo feature. there might be a point where i want to purge the possibility to do an undo (like at the end of the session).

[DC-169] replace() method does not affect Timestampable fields

Tue, 3 Nov 2009 03:32:42 +0000

I have a Timestampable behavior on a table. If I create or edit an object of this table using the ->replace() method instead of ->save(), the Timestampable fields (created_at and updated_at by default) are not changed.

[DC-167] Adding a foreign key to the uniqueBy option of a Sluggable doesn't work

Tue, 3 Nov 2009 02:22:42 +0000

I'm trying to set the uniqueBy option of a Sluggable to a foreign key (in an articles table, I want the slug to be unique by category). This fails because the query checking if the slug exists doesn't return any records, as it doesn't use the correct where paramter.
The problem is in Doctrine/Template/Listener/Sluggable.php:172, adding the whereParam expects a value, but a class (containing the relationship object) is given.

        foreach ($this->_options['uniqueBy'] as $uniqueBy) {
            if (is_null($record->$uniqueBy)) {
                $whereString .= ' AND r.'.$uniqueBy.' IS NULL';
            } else {
                $whereString .= ' AND r.'.$uniqueBy.' = ?';
                $whereParams[] =  $record->$uniqueBy;
            }
        }

[DC-165] outdated symfony Yaml parser causes troubles

Tue, 3 Nov 2009 01:10:35 +0000

all doctrine versions use an imported and modified version of sfYaml.
Either that needs to be changed to an external, or bugfixes need to be ported.
see this ticket from symfony trac:
http://trac.symfony-project.org/ticket/7496

I wanted to use some yaml in a fixture to populate data for the "array"-Fieldtype.

In the fixture I used:
items:
  -
    name:           temp_zone_1
    fieldLabel:     Temp. Zone 1 [°C]
    value:          997
    minValue:       0
    maxValue:       3000
...
the resulting serialized array in the table array looked like:
s:5:"items";a:9:{i:0;a:5:{s:4:"name";s:11:"temp_zone_1";s:10:"fieldLabel";s:18:"Temp. Zone 1 [°C]";s:5:"value";s:3:"997";s:8:"minValue";i:0;s:8:"maxValue";s:4:"3000";}...
There you can easily see, that "value" is now a string, "minValue" an integer (why?) and maxValue another string. This went awfully wrong somewhere.

= Workaround and/or solution =
I took the current parser from `lib/yaml/sfYamlParser.php` and copied it into the existing Parser in `lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Parser/YamlSf/Parser.php`. That fixed the problem.

== Additional Information ==

used Version in Symfony 10832 2008-08-13

used Version in sfDoctrinePlugin 8869 2008-05-09

HTH,
Michael

used Version in Symfony	10832 2008-08-13
used Version in sfDoctrinePlugin	8869 2008-05-09

[DC-164] Validator throws out a 'boolean' with null value.

Tue, 3 Nov 2009 04:36:01 +0000

I didn't set a value into a boolean column, reckoning that null would count as false.

But saving the record fails validation, and this appears to be because Doctrine_Validator::isValidType contains

case 'boolean':
return is_bool($var) || (is_numeric($var) && ($var == 0 || $var == 1));

So it will not accept a null value, and furthermore reports the failure not as a data error but (confusingly) as a type error.

I checked the documentation to see if it said that I could not use a null value (I would regard this as an unnecessary restriction, but at least if it were documented, that would be consistent).

On the contrary, the Doctrine ORM book, Chapter 7, in the 'Boolean' section, says "Ternary logic is possible by using null as the third possible value that may be assigned to fields of this type."!

Add this to the fact that I haven't found any documentation about using Doctrine_Validator_Exception - not even API documentation, and I am not impressed with my first experiences with Doctrine.

[DC-163] Validator throws out a data type which the schema processing has accepted

Tue, 3 Nov 2009 04:35:14 +0000

Doctrine accepts 'char' in the (yml) schema, and creates the database and model.
Then an attempt to save a record raises a Doctrine_Validator_Exception, which turns out to contain no validation message, but just the cryptic
[_errors:protected] => Array
(
[nickname] => Array
(
[0] => type
)

)

[_validators:protected] => Array
(
)

Only by looking at the source did I discover that what this means is that the validator does not accept the column type 'char' - because it's not hard-coded in Doctrine_Validator::isValidType.

I've vacillated over whether to classify this as 'Major' or Minor': once I've realised what's going on, it's easy to work round; but it is a show-stopper for a Doctrine novice.

[DC-162] Doctrine_Migration_Builder fail to buildChangeColumn()

Mon, 2 Nov 2009 20:14:49 +0000

Doctrine_Migration_Builder->buildChangeColumn contains a simple error.

return "        \$this->changeColumn('" . $tableName . "', '" . $columnName. "', '" . $length . "', '" . $type . "', " . $this->varExport($column) . ");";

When I look Doctrine_Migration_Base->changeColumn declaration, i see

public function changeColumn($tableName, $columnName, $type = null, $length = null, array $options = array())

The $length and $type parameters are inverted. It makes all column changes fail.

Thank you for your work, Doctrine is great !

[DC-159] No use of Offset in the Limit / Offset Documentation

Fri, 30 Oct 2009 16:33:53 +0000

There is no mentioning how to use the offset funktion in the "LIMIT and OFFSET clauses" chapter in the Doctrine 1.1 Documentation.

Some Example should feature:

->limit(12)
->offset(3)

to show how to use it.

[DC-158] Postgresql Import does not recognize all parts of a composite primary key as primary keys

Tue, 3 Nov 2009 00:42:32 +0000

If a PostgreSQL table has a composite primary key, Doctrine import ("generate-models-db") will only mark the first column of the composite key as primary. This is due to a bug in Doctrine_Import_Pgsql.

I have attached a short patch against the current 1.1 branch (revision 6580). The version 1.2 seems to have the same problem.
I have tested the patch with PostgreSQL 8.3.8.

[DC-155] Missing part of the description for code examples in "Working with Models" chapter

Tue, 3 Nov 2009 20:47:32 +0000

in chapter "Working with models", explanations for 2 code examples are missing a part : ", excluding the group named Group 2"

patch attached.

[DC-154] Documentation fixes in several chapters

Tue, 3 Nov 2009 20:49:10 +0000

several fixes attached as patch :

missing "have" in note in introduction chapter
"DQL" instead of "SQL" in explanation for getSql in DQL chapter
explanations uses property "password", whereas the example code uses "description" in chapter Working with models
extra line breaks in Synchronize with Array in chapter Working with models
word "their" was used instead of "there" in several sentences

[DC-153] Some pieces of Doctrine's internal code can't work properly without a default connection

Tue, 3 Nov 2009 02:19:25 +0000

For details see thread in doctrine-dev group.

[DC-152] isModified deep isn't working when only deep objects are modified

Mon, 2 Nov 2009 23:45:13 +0000

Record::isModified(true) isn't working when only a subobject is modified (it returns false).
The attached patch corrects the problem.

[DC-151] Doctrine_Collection::loadRelated() issues with empty collection and handling with no name parameter

Fri, 30 Oct 2009 17:04:20 +0000

When no name is passed, the list variable isnt passed to the where() method call. Also in all cases an empty $list variable isnt handled properly.

[DC-148] When running cli tasks and there's an exception/error - it's helpful to have detailed information displayed

Tue, 3 Nov 2009 02:18:28 +0000

We don't always get enough information when an exception happens to track down where the issue is.
It would be helpful if the tablename and/or the SQL statement was also displayed to help track down problems.

When trying to load a fixture file I was receiving the following:
[Doctrine_Connection_Mysql_Exception]
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'created_at' cannot be null

As you can see - it doesn't help much as it doesn't display the table/class that's the created_at column is on.

As quick fix - I modified the rethrowException method in Doctrine_Connection to include some information from the invoker (not a great fix - I should really dig deeper and see if there's a __toString() method on classes that can be passed as the invoker):

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

    /**
     * rethrowException
     *
     * @throws Doctrine_Connection_Exception
     */
    public function rethrowException(Exception $e, $invoker)
    {
        $event = new Doctrine_Event($this, Doctrine_Event::CONN_ERROR);

        $this->getListener()->preError($event);
        
        $name = 'Doctrine_Connection_' . $this->driverName . '_Exception';
        
        $exc  = new $name($e->getMessage() . "\n" . $invoker->getQuery(), (int) $e->getCode());
        if ( ! isset($e->errorInfo) || ! is_array($e->errorInfo)) {
            $e->errorInfo = array(null, null, null, null);
        }
        $exc->processErrorInfo($e->errorInfo);

         if ($this->getAttribute(Doctrine_Core::ATTR_THROW_EXCEPTIONS)) {
            throw $exc;
        }
        
        $this->getListener()->postError($event);
    }

[DC-147] In doctrine 1.2 load_data fails with a bogus error when id holders are repeated

Tue, 3 Nov 2009 02:02:44 +0000

Schema fragment:
Invoice:
actAs:
Timestampable: ~
tableName: invoice
columns:
id:
type: integer(4)
primary: true
autoincrement: true
billingDate:
type: date
dueDate:
type: date
hostingAccount_id:
type: integer(4)
relations:
invoiceItems:
class: InvoiceItem
local: id
type: many
foreign: invoice_id
foreignType: one

#
InvoiceItem:
actAs:
Timestampable: ~
tableName: invoiceItem
columns:
id:
type: integer(4)
primary: true
autoincrement: true
name:
type: string(100)
quantity:
type: integer(4)
cost:
type: decimal(10)
scale: 2
notnull: false
default: null
invoice_id:
type: integer(4)

With the following fixture fragment:

Invoice:
testInvoice01:
billingDate: "2009-11-11"
dueDate: "2009-11-16"
owningAccount: TestAcc01
invoiceItems:
invItem01:
name: TestLine01
quantity: 2
cost: 12.99
invItem02:
name: TestLine02
quantity: 1
cost: -2.50

testInvoice02:
billingDate: "2009-11-11"
dueDate: "2009-11-21"
owningAccount: TestAcc01
invoiceItems:
invItem01:
name: TestLine03
quantity: 2
cost: 12.99
invItem02:
name: TestLine04
quantity: 1
cost: -2.50

The reuse of the invItem01 & invItem02 tags - even as children of separate parents causes an error.
The reported error was very confusing:

[Doctrine_Connection_Mysql_Exception]
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'created_at' cannot be null

Making the child tags unique fixed the issue.
The same fixture loaded without problems in Doctrine 1 (I think 1.0.18 but it's not listed in the released versions above).

[DC-146] GenerateMigrationsDiff task does not use new order of changeColumn()

Fri, 30 Oct 2009 15:46:36 +0000

The GenerateMigrationsDiff task generates migrations which still use the old ordering of parameters of changeColumn().

This is how it gets generated:

$this->changeColumn('my_table', 'my_column', '25', 'timestamp', array(
'notnull' => '1',
));

Why it should be like this

$this->changeColumn('my_table', 'my_column', 'timestamp', '25', array(
'notnull' => '1',
));

I also added a patch to fix this.

[DC-144] Doctrine_Manager::getConnectionForComponent() should use Doctrine_Core::modelsAutoload()

Tue, 3 Nov 2009 01:54:09 +0000

Doctrine_Manager::getConnectionForComponent() tries to pre-load given component using Doctrine_Core::autoload().
But it seems it should be modelsAutoload() instead, because just autoload() has nothing to do with model classes.

See also corresponding topic in the doctrine-dev group.

[DC-141] Invalid fix [6568] for DC-132

Fri, 30 Oct 2009 16:57:30 +0000

Changeset [6568] looks incorrect, it always binds parameters as if they were positional thus not by name :MYPARAM. Therefore for queries with named parameters a PDO exception will be thrown.

Btw, I wanted to reopen Jira ticket ~~DC-132~~ for this, but how do I do that?

[DC-137] Doctrine_Record_Generator does not autoload classes

Wed, 2 Dec 2009 16:55:14 +0000

Using the versionable behavior creates dynamic classes and does not autoload the models that are defined. Removing the false flag from if ($this->_options['generateFiles'] === false && class_exists($this->_options['className']. false )) { line will fix the issue

[DC-135] Nested i18n versionable behaviour

Sun, 13 Dec 2009 15:37:50 +0000

Sorry to bring this up again (http://trac.doctrine-project.org/ticket/1708), but the current ALPHA 3 works perfectly on MySQL and fails on PostgreSQL. I tried the simple wiki example on a fresh project. I posted it already on google groups, but it seems this is the right place for that: http://groups.google.com/group/doctrine-user/browse_thread/thread/32208d921dffb8b3/63eb7337015f4415?show_docid=63eb7337015f4415

This is the generated postgresql sql file:

CREATE TABLE wiki_translation_version (id BIGINT, lang CHAR(2), title VARCHAR(255), content TEXT, version BIGINT, PRIMARY KEY(id, lang, version));
CREATE TABLE wiki_translation_index (id BIGINT, lang CHAR(2), keyword VARCHAR(200), field VARCHAR(50), position BIGINT, PRIMARY KEY(id, lang, keyword, field, position));
CREATE TABLE wiki_translation (id BIGINT, title VARCHAR(255), content TEXT, lang CHAR(2), version BIGINT, slug VARCHAR(255), PRIMARY KEY(id, lang));
CREATE TABLE wiki (id BIGSERIAL, created_at TIMESTAMP NOT NULL, updated_at TIMESTAMP NOT NULL, PRIMARY KEY(id));
CREATE UNIQUE INDEX sluggable ON wiki_translation (slug);
ALTER TABLE wiki_translation_version ADD CONSTRAINT wiki_translation_version_id_wiki_translation_id FOREIGN KEY (id) REFERENCES wiki_translation(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE;
ALTER TABLE wiki_translation_index ADD CONSTRAINT wiki_translation_index_id_wiki_translation_id FOREIGN KEY (id) REFERENCES wiki_translation(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE;
ALTER TABLE wiki_translation ADD CONSTRAINT wiki_translation_id_wiki_id FOREIGN KEY (id) REFERENCES wiki(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE;

The error is:

SQLSTATE[42830]: Invalid foreign key: 7 FEHLER: in Tabelle »wiki_translation«, auf die verwiesen wird, gibt es keinen Unique Constraint, der auf die angegebenen Schlüssel passt. Failing Query: ALTER TABLE wiki_translation_version ADD CONSTRAINT wiki_translation_version_id_wiki_translation_id FOREIGN KEY (id) REFERENCES wiki_translation(id) ON UPDATE CASCADE ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE

It is in german but it means something like: there is no unique constraint in table 'wiki_translation' matching the given key.

Michael

[DC-132] LOB mode not used for BLOB fields that are specified as a file handle

Sat, 24 Oct 2009 00:55:13 +0000

PDO provides us with the (highly desirable) possibility of providing the contents for a blob file through a filehandle resource, so the data can be read directly from a file or another stream source. When retrieving blob data from the database, I already get such file handle back. However, when creating of updating a record with a blob field using a filehandle, this fails. It fails because of two issues:

Doctrine_Validator::isValidType() rejects the resource handle, because blob fields are only checked using is_string().

$sth->execute($params) is used for executing a query after preparing it. The $params are provided straight away to the statement handle, without differentiating between field types by means of explicit bindings. An explicit binding with Doctrine::PARAM_PDO would be needed to allow for field data upload using a filehandle.

I have already been going over the code and I could not find a very good spot for handling this. What functionally should happen is that:

a blob field
for which a stream resource is set
should not be rejected as a valid blob type field and
should be bound as a param to the prepared insert/update query
using the data type Doctrine::PARAM_LOB

In the attached patch, I have updated the code in a way that makes this feature work. What I did feels like a hack, but I couldn't find a good way to implement this cleanly. The type of field that we are handling (blob or not?), the data that we are handling (resource or not?) and the spot where we can use bindParam() are not really tightly interconnected (or maybe they are and I overlooked it).

[DC-130] Doctrine::generateModelsFromDb fails on foreign key relationships with certain table names on Postgresql

Tue, 3 Nov 2009 01:48:47 +0000

Create the following tables:

CREATE TABLE "user" (
id serial PRIMARY KEY,
name varchar(30) NOT NULL
);

CREATE TABLE "group" (
id serial PRIMARY KEY,
name varchar(30) NOT NULL
);

CREATE TABLE "user_x_group" (
id serial PRIMARY KEY,
user_id int NOT NULL REFERENCES "user" ( id ),
group_id int NOT NULL REFERENCES "group" ( id ),
UNIQUE ( user_id, group_id )
);

If you try to run Doctrine::generateModelsFromDb() it will crash with
Uncaught exception 'Doctrine_Import_Builder_Exception' with message 'Missing class name.'

This is caused by the fact that the table 'user' (and 'group' also, for that matter) is escaped with quotes when
passed through pg_get_constraintdef, because 'user' (and 'group') is a reserved word.

A solution would be to modifiy the regexp in Doctrine_Import_Pgsql::listTableRelations so that it strips the quote characters
from identifiers.

[DC-128] search is using default connection for query not the indexed table's connection

Mon, 2 Nov 2009 23:41:17 +0000

I'm using two databases with two connections, one of these only in one component of the project.

I used Doctrine_Manager::bindComponent to set the connection for the tables of the second database, and left the main database's connection as default.

The bug happens when I'm using search() in a searchable table of the second database. Doctrine_Search::search function uses the default connection when queries the index table, instead of the connection bound to the searchable table.

I attached a patch, which works for me.

[DC-127] Allow a class prefix to be specified when calling Doctrine_Core::loadModels()

Mon, 2 Nov 2009 23:34:51 +0000

Doctrine allows you to generate class names such as Blog_Model_Post in Post.php, but Doctrine::loadModels() is not able to load these models conservatively, as the class name and file name differ.

I suggest adding a third parameter to Doctrine_Core::loadModels() to specify a class prefix, for example:

Doctrine_Core::loadModels('/modules/blog/models', Doctrine_Core::MODEL_LOADING_CONSERVATIVE, 'Blog_Model_');

Code changes (I think) would be something like this:

public static function loadModels($directory, $modelLoading = null, $classPrefix = null)
{
...
	$className = $e[0];
	
	if ($classPrefix) {
		$className = $classPrefix . $className;
	}
...
}

Since the argument is optional, this change shouldn't break any existing code.

NB: This is not PEAR-style file/class naming.

[DC-116] getParent() works as getRoot() in NestedSet behavior

Mon, 2 Nov 2009 22:48:37 +0000

This is current version of getParent()

public function getParent()
    {
        $baseAlias = $this->_tree->getBaseAlias();
        $q = $this->_tree->getBaseQuery();
        $q->addWhere("$baseAlias.lft < ? AND $baseAlias.rgt > ?", array($this->getLeftValue(), $this->getRightValue()))
                ->addOrderBy("$baseAlias.rgt asc");
        $q = $this->_tree->returnQueryWithRootId($q, $this->getRootValue());
        $result = $q->execute();
        if (count($result) <= 0) {
            return false;
        }
               
        if ($result instanceof Doctrine_Collection) {
            $parent = $result->getFirst();
        } else if (is_array($result)) {
            $parent = array_shift($result);
        }
        
        return $parent;
    }

As you can see, this method does not have level limit in where clause. If tree have more than 2 levels in depth, method will return root node of the tree, not parent.

My fix is use level limit:

public function getParent()
    {
        $baseAlias = $this->_tree->getBaseAlias();
        $q = $this->_tree->getBaseQuery();
        $q->addWhere("$baseAlias.lft < ? AND $baseAlias.rgt > ?", array($this->getLeftValue(), $this->getRightValue()))
                ->addOrderBy("$baseAlias.rgt asc");
        $q->addWhere("$baseAlias.level >= ?", $this->record['level'] - 1);
        $q = $this->_tree->returnQueryWithRootId($q, $this->getRootValue());
        $result = $q->execute();
        if (count($result) <= 0) {
            return false;
        }
               
        if ($result instanceof Doctrine_Collection) {
            $parent = $result->getFirst();
        } else if (is_array($result)) {
            $parent = array_shift($result);
        }
        
        return $parent;
    }

PS. Sorry for my english.

[DC-115] Doctrine_Cli and Doctrine_Task: further improvements to creation and registration of custom tasks

Fri, 23 Oct 2009 17:41:43 +0000

Having worked with - and experienced the 'inconveniences' of - my previous changes (see r6475), I have made further improvements to Doctrine_Cli, and a small change to Doctrine_Task, and have achieved the following.

Creating and working with custom tasks is now even easier.
Doctrine_Cli is even more powerful since it is now that much easier to extend.
Doctrine_Cli is more testable - though there's still room for improvement.

The enclosed patch was created against 1.2 r6535. I have merged changes committed since r6475 - Jon's changes in r6484.

Further details:

Doctrine tasks are always included and 'registered' on startup. By default, loaded custom tasks are then registered.

Custom tasks need only extend Doctrine_Task - there are no special naming conventions to follow.

Automatic loading of custom tasks can be disabled by setting the new "autoregister_custom_tasks" config option to FALSE (TRUE is the default).

The following code includes and registers Doctrine core Tasks, and then registers loaded custom tasks.

$cli = new Doctrine_Cli();
$cli->run($_SERVER['argv']);

The following code includes and registers only Doctrine core Tasks.

$oCli = new Doctrine_Cli(array('autoregister_custom_tasks' => false));
$oCli->run($_SERVER['argv']);

The following code includes and registers Doctrine core Tasks, and then registers a custom task loaded after the CLI was instantiated.

$oCli = new Doctrine_Cli();

require_once(dirname(_FILE_) . '/TestTask02.php');

//Either...:
$oCli->registerTaskClass('Doctrine_Cli_TestCase_TestTask02');
//...Or:
$oCli->registerIncludedTaskClasses();

$oCli->run($_SERVER['argv']);

(These code examples can be found in /tests/CliTestCase.)

Responsibility for naming tasks lies with the tasks themselves. Tasks will still receive a name derived from the fully-qualified (i.e. including namespaces) name of their class, but it is now possible to specify the name at design time - you might want to do this if the default task name would be very long or undesirable for some reason.

For example:

namespace fully\qualified;

class CustomTaskName extends \Doctrine_Task {

//This task would otherwise be registered as "fully-qualified-custom-task-name"
public $taskName = 'custom-task-name';

public function execute () {}
}

A CLI can now be instructed to rethrow exceptions. This is very useful if you're running a batch of tasks in a single script and you need processing to stop if one of them fails.

Simply set the new "rethrow_exceptions" config option to TRUE to enable this behaviour - the default is FALSE.

For example:

$oCli = new Doctrine_Cli(array(
'autoregister_custom_tasks' => false,
'rethrow_exceptions' => true,
));

$oCli->run($_SERVER['argv']);

I think there are still one or two things I'd like to look at, but I wanted to get the bulk of the work in so I don't hold you up.

Oh, and I'd like to apologise for having moved everything around. I wouldn't normally, but in trying to make sense of things, I found it necessary.

[DC-114] calculateQueryCacheHash / calculateResultCacheHash with pendingJoinConditions

Tue, 3 Nov 2009 01:26:39 +0000

I've modified SoftDelete so that the preDqlSelect part is only applied when a specific param in the Manager is set. Currently this works like expected, but I've discovered a small problem, when I've enabled the QueryCache:

Since SoftDelete adds the "where is_deleted=0" as a pendingJoinCondition it isn't taken into account by the calculateXXXCacheHash function

I've made a small patch to Query/Abstract.php that takes the pendingCondition into account

[DC-110] Doctrine_Export_Mysql does not quote tableName in createIndexSql()

Tue, 3 Nov 2009 01:21:31 +0000

Very simple issue, seems that has been forgotten in this case. One of us in the developer team had the great idea to name a table "group". So we need quoting And adding a index on this table within a migration was not possible because the table name doesn't get quoted when adding an index..

So I added the tiny patch necessary to correct this.. I know it's not impressing but it's a fix Maybe it gets in the maintenance release 1.1.5 before the 2.0 stable comes out (if there is anything more in the 1.1.* line)..

[DC-103] doctrine 1.0 not getting table correctly - huge bug - not usable

Fri, 30 Oct 2009 17:35:45 +0000

In the method coreSetRelated from Record.php for 1-1 relation the table is not obtained correctly!

if ($value !== self::$_null)

{ $relatedTable = $value->getTable(); $foreignFieldName = $relatedTable->getFieldName($rel->getForeign()); }

instead of

$relatedTable = $value->getTable();

you should put

$relatedTable = $rel->getTable();

This is a huge bug that can be fixed very easily so please fix is asap!

I can not deploy my project until this is fixed!

Thanks a lot!

I do not know if other versions are affected! I use symfony 1.2.9! Should I make a ticket also for Symfony!

You do a great job with doctrine! Great project! I really like it

[DC-96] Add support for the SET datatype

Tue, 3 Nov 2009 05:19:34 +0000

Similar to the ENUM datatype, MySQL also invented the SET datatype. Emulation should be easily doable just like its currently done for ENUM.
http://dev.mysql.com/tech-resources/articles/mysql-set-datatype.html

[DC-93] Calling refreshRelated causes hasOne records to be created in error

Fri, 30 Oct 2009 17:31:23 +0000

Calling save() on a record, then refreshRelated(), then save() again will cause hasOne rows to be generated in error. I've attached a Doctrine sandbox with everything you need to reproduce it. Below is a summary.

schema.yml

schema.yml

 
---
Staff:
  columns:
    username: string(50)
    password: string(255)
    active:
      type: boolean
      default: true
  indexes:
    user_pass_active_idx:
      fields: [username, password, active]


Tickets:
  columns:
    mask:
      unique: true
      type: string(10)
    staff_id: integer(9)
  relations:
    Staff:
      local: staff_id
      foreign: id

Test.php

 
<?php
$ticket = new Tickets();
$ticket->save();
$ticket->refreshRelated();
$ticket->save();

Queries that were run:

root@localhost on doctrine11sandbox
START TRANSACTION
INSERT INTO tickets (id, mask, staff_id) VALUES (NULL, NULL, NULL)
COMMIT
START TRANSACTION
*INSERT INTO staff (active) VALUES ('1')*
UPDATE tickets SET staff_id = '2' WHERE id = '2'
COMMIT

[DC-87] Import / export does not take into account the connection to the database

Fri, 30 Oct 2009 16:14:56 +0000

The mechanism of imports and exports does not include connection to the database. This creates many problems when we have multiple connections to the database and want to use a command to generate. (generateYamlFromDb or generateYamlFromModels or generateModelsFromDb or generateModelsFromYaml and other related methods)

Possible solution:

The file Doctrine/Import.php between lines 384 and 385 insert:
$definition['connection'] = $connection->getName();
$definition['connectionClassName'] = $definition['className'];

The file Doctrine/Export/Schema.php between lines 71 and 72 insert line:
$table['connection'] = $recordTable->getConnection()->getName();

[DC-74] Condition of STATE_PROXY should be checked dynamically, not as a static state value

Mon, 2 Nov 2009 22:34:10 +0000

This issue is continuation of issue #2488 from Trac. I have prepared Test case showing that the problem is seriously. Below original content.

A record gets STATE_PROXY state at hydration when its properties are not fully loaded. Here is a condition (placed in Doctrine_Record::hydrate()):

if ( ! $this->isModified() && count($this->_values) < $this->_table->getColumnCount()) {
   $this->_state = self::STATE_PROXY;
}

But at first setting a column value (whatever if the column value was loaded or not), the record gets STATE_DIRTY and "forgets" its proxy state.

In effect a call to any not loaded column of the record causes returning null value. It should, of course, load remaining column values and change record state from STATE_PROXY to STATE_DIRTY. It doesn't load because current record state is already STATE_DIRTY.

I'm attaching a patch, which fixes Doctrine_Record::load() in the described situation.

In my opinion usage of STATE_PROXY must be rethinked. STATE_PROXY can mean:
1. STATE_CLEAN + not fully loaded columns (proxy)
2. STATE_DIRTY + not fully loaded columns (proxy)

Currently it only points the first situation so there is not way to identify the second situation (and it is silently ignored).

[DC-73] TestCase framework normally uses identityMap for records created in prepareData() what can cause side effects

Fri, 30 Oct 2009 17:17:02 +0000

All new records are stored in the identityMap during insertion. This default behavior takes place also while executing test cases.

In other words every record created in the prepareData() method gets to the identityMap. Afterwards, in a test method, it is silently retrived from identityMap instead of (expected!) quering from sqlite.

IMHO a testing environment should be as pure as possible and no such side effects are acceptable.

I'm including a test case and patch for Doctrine_UnitTestCase. After putting the patch, I have found that 2 test cases causes fail: 1449 and 736. In the first test IMHO there is a problem in a content test - I'm including appropriate fix.
It seems that the second test, in fact, have never been passing. I think that positive result was caused by the side effect of identityMap.

[DC-69] Linking between one to one relations with synchronizeWithArray fails

Mon, 2 Nov 2009 20:13:37 +0000

Linking between one to one relations with synchronizeWithArray() ends up in an error message.

Example:
Group has one User
User has one Group

When I have a group-object and do the following:

$group->synchronizeWithArray(array(
	'User' => array(1)
));
$group->save();

I get the message: "Fatal error: Call to a member function identifier() on a non-object in [..]lib/Doctrine/Record.php on line 2327"

Apparantly $this->_references[$alias] should be an collection, but in an one to one relation it is a record (which makes sense in my opinion).

[DC-65] Add documentation for Doctrine::ATTR_HYDRATE_OVERWRITE

Tue, 3 Nov 2009 20:14:55 +0000

Maybe this sould be added somewhere in docs (since there's nothing about that in 1.1's)

$manager->setAttribute(Doctrine::ATTR_HYDRATE_OVERWRITE, false);

[DC-55] Add documentation for record filters

Tue, 3 Nov 2009 20:03:53 +0000

There's nothing in the 1.0 documentation about Doctrine_Record_Filter. Would be nice because it's a handy feature!

[DC-39] Linking between one to many relations with synchronizeWithArray fails

Mon, 2 Nov 2009 20:14:05 +0000

Linking between one to many relations with synchronizeWithArray() has a strange behavior.

Example (fully example is in the attachment):
Group has many Users
User has one Group

When I have a group-object (id 2) and do the following:

$group->synchronizeWithArray(array(
	'Users' => array(1,2)
));
$group->save();

on the first execute of the script the users with id 1 and 2 are linked to group 2 (with foreign key = group_id in user table) -> right
on the second execute of the script the users with id 1 and 2 are linked to null -> failure
on the third execute of the script the users with id 1 and 2 are linked to group 2 -> right
on the fourth execute of the script the users with id 1 and 2 are linked to null -> failure
and so on

I tried to find the error on my self, but had no luck.
That's what I have found:
On every script-execution the relations to group 2 are first nulled.
If they were allready null für user 1 and 2, the relations are build with an update -> right!; but when this two users had allready this relation they are only nulled and no update is processed.
Thats why there is this strange toggling on the foreign key on every script execution.

Maybe it has something to do with the record_state which is clean, when the relations are allready set in the DB -> no update is executed, but the nulling of all foreign key linked to group 2.