Calling Doctrine_Manager::resetInstance() resets the instance, however opening a new instance (and new connections) produces an error in the line 221 of Doctrine_Connection:

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

Which is because Doctrine_Manager::setDefaultAttributes() has a static variable $init in that function, hence reset instance is not resetting it and new manager instance looses default attributes.

Proposed fix: move $init variable to the object level.

This bug was discovered while using getDescendants with the new toHierarchy function. Rather than containing the correct child elements in the __children field, it contains whatever the next record is. Each record only has a single child, which is the record with the next-highest lft value. You can see this in the following pastebin. Notice that the very bottom element is placed around level 15 in the tree, yet it should be level 4 according to the "level" field.

The line that was used to produce the above pastebin was:
print_r($children = $file->getNode()>getDescendants(null, false)>toHierarchy()->toArray());
The class used for $file is: http://pastebin.ca/1673706

In Doctrine_Cache_Driver::::deleteByPrefix() on line 216 you can read:

if (strpos($key, $prefix) == 0) ...

to check whether the prefix starts on the first position.
As strpos() returns false if the prefix is not found at all and 0 evaluates to false this results to the deletion of unnecessary cache keys.

correct would be:

if (strpos($key, $prefix) === 0) ... // triple '='

Need a simple method for determining if a mapped value has been defined. The attached diff is against an earlier revision of Doctrine_Record, but it's just a couple of lines of code so it can easily be inserted manually.

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:

columns:
name:

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.

If class prefixes are being used with inheritance, the items in the setSubClasses array do not include the class prefix. I only tested this with column aggregation. Assuming that the prefix is "Default_Model_", the below example generates a "Default_Model_User" and "Default_Model_UserAdmin" class.

Inside the Default_Model_User class, this is generated:
$this->setSubClasses(array('UserAdmin' => array('coursetype' => 1)));

but it should be:
$this->setSubClasses(array('Default_Model_UserAdmin' => array('coursetype' => 1)));

Example schema:

User:
columns:
id:
primary: true
type: integer(4)
unsigned: 1
autoincrement: true
name:
type: string(255)
notnull: true
type:
type: integer(4)
unsigned: 1

UserAdmin:
inheritance:
extends: User
type: column_aggregation
keyField: type
keyValue: 1
columns:
test:
type: integer(1)
unsigned: 1
default: 128

In Doctrine/Import/Builder.php, if pear style generation is enabled, underscores are replaced with slashes to create the Pear style directory layout. The code that builder.php uses is below.

if ($this->_pearStyle) {
$writePath = str_replace('_', '/', $writePath);
}

If the models_path contains an underscore, for example "D:\Inetpub_EXT\app\models", the underscore also gets converted to a slash. All of the models end up being created in the "D:\Inetpub\EXT\app\models" directory.

This is obviously wrong since cloning should result in identical object, but why this is such a critical bug is because it breaks setting array hydration for nested set base query, because the query object gets cloned during the fetching of tree. This bug was introduced in revsion 6691 in attempt to fix DC-204. Included is a patch that correctly clones the hydrator instead of resetting its information completely.

Should be changed to Doctrine_Core. See attached patch file.

The second Doctrine_Migration instance is unusable.

It is very easy to reproduce the bug :

// first instance
$migration = new Doctrine_Migration('/path/to/migration/classes');
print_r($migration->getMigrationClasses()); // will work, and show the migration classes as expected

// same code, second instance
$migration = new Doctrine_Migration('/path/to/migration/classes');
print_r($migration->getMigrationClasses()); // will not work. No more migration classes displayed.

This is due to the fact that Doctrine_Migration->loadMigrationClassesFromDirectory only registers classes that are not already loaded :

$array = array_diff(get_declared_classes(), $classes);
$className = end($array);

If a migration class is already declared ( ie the second time we use Doctrine_Migration ), it will not be recognized.

Thank you for your great work.

after upgrade of doctrine version ( as a part of symfony upgrade) now creates new "camelcase" names insted of the existing classes (e.g. "Tbl_My_Table" replaced to "TblMyTable"), the problematic function is "importSchema" in the attched "Import.php" file. i have added remarks to the lines that creates the the error.

The fix for DC-204 in changeset [6691] is incorrect. I have a model using the nested set plugin. When I set hydration mode HYDRATE_ARRAY on its base query and perform a query objects are returned instead of arrays. I think this is due to the fact that clones of the query should take over the selected hydration mode. Please have a look.

Doctrine allows schema files (schema.yml in my case as symfony user) to define global settings that shall be valid for each class (within the same schema file) to be taken as default unless specified otherwise within the class.
However, once an individual class does specify (even only) one single option, none of the global options are being used anymore at all. This is the current implementation as of in Doctrine_Import_Schema::parseSchema(), line 330.
IMHO this implementation makes the feature of rather little benefit for users, particularly because 'options' is an array, even a nested one since symfony 1.3 did introduce their own options therein ('forms' and 'filters').

Following example:

# global settings, as default for all classes
detect_relations:                   false
options:
    type:                           innodb
    collate:                        utf8_unicode_ci
    charset:                        utf8
    symfony:
        form:                       true
        filter:                     true

DocumentSource:
    tableName:                      dk_doc_source
    abstract:                       'Possible sources for documents (code set)'
    options:
        symfony:                    { filter: false }
    actAs:
        Timestampable:              ~
    columns:
        name:                       { type: string(63), notnull: true }
        description:                { type: string(255) }

DocumentType:
    tableName:                      dk_doc_type
    abstract:                       'Allowed types for documents'
    options:
        symfony:                    { form: false, filter: false }
    actAs:
        Timestampable:              ~
    columns:
        name:                       { type: string(63), notnull: true }
        description:                { type: string(255) }

DocumentTag:
    tableName:                      dk_doc_tag
    abstract:                       'Tags for documents'
    actAs:
        Timestampable:              ~
    columns:
        name:                       { type: string(63), notnull: true }
        description:                { type: string(255) }

After an import with the current implementation, the classes end up having the following options:

• DocumentSource:

      options:                             # taken from the specific class, no global setting was taken over
          symfony:                    { filter: false }
  

• DocumentType:

      options:                            # taken from the specific class , again no global setting was taken over
          symfony:                    { form: false, filter: false }
  

• DocumentTag:

  options:                            # taken from the globals
      type:                           innodb
      collate:                        utf8_unicode_ci
      charset:                        utf8
      symfony:
          form:                       true
          filter:                     true
  

As a developer I originally understood the feature in that DocumentSource and DocumentType would still get the global option settings like collate, charset etc without having to repeat them again and again.

• Like e.g. for DocumentSource:

  options:                            # global and class specific options brought together
      type:                           innodb
      collate:                        utf8_unicode_ci
      charset:                        utf8
      symfony:
          form:                       true
          filter:                     false
  

--> is the effect of the current implementation is intentional?
I.e. I wish to raise the question: shall globals...

1. only be applicable to an individual class if the latter doesn't specifiy any option at all? (principle of XOR), or
2. complement the class' individual options, i.e. the developer defines the desired default options as globals, and specifies any difference from that in the individual class? (principle of inheritance).

IMHO as a user of Doctrine & Symfony, I cleary prefer the inheritance principle (2).

A thinkable solution is to use array_replace_recursive() or a similar function instead of a simple assignment:

CURRENT:
        // Apply the globals to each table if it does not have a custom value set already
        foreach ($array as $className => $table) {
            foreach ($globals as $key => $value) {
                if ( !isset($array[$className][$key])) {
                    $array[$className][$key] = $value;
                }
            }
        }
PATCH:
        // Apply the globals to each table if it does not have a custom value set already
        foreach ($array as $className => $table) {
            foreach ($globals as $key => $value) {
                   $array[$className][$key] = array_replace_recursive($value, $array[$className][$key]);    // do inherit the global settings
            }
        }

I haven't yet tried out this patch nor even tested it, since anything first depends from a clarification on the common expectations from the feature of globals in schema files.

Cheers, RAPHAEL

PS. update: I created a corresponding issue in Symfony trac.

The code for Doctrine_Node_NestedSet::hasParent() will return true if a Doctrine_Record is not yet a valid node. The code for hasParent() returns the inverse of Doctrine_Node_NestedSet::isRoot() which returns false for both non-root nodes and non-valid nodes. I believe a call to Doctrine_Node_NestedSet::isValidNode() should be included in this function to prevent this issue.

When generating models like this:

'pearStyle' => true,
'generateTableClasses' => true,
'classPrefix' => 'Model_',
'baseClassPrefix' => 'Base_',
'baseClassesDirectory' => null,
'classPrefixFiles' => false,
'generateAccessors' => false,

Or any other similar style which includes models prefix, comments generated are like this:

/**
* Model_Base_Class
*
* This class has been auto-generated by the Doctrine ORM Framework
*
* @property integer $id
* @property Operators $Operators
*
* @package -
* @subpackage -
* @author -
* @version SVN: $Id: Builder.php 6698 2009-11-10 17:58:02Z jwage $
*/

Problem is with line "@property Operators $Operators" which is incorrect (even though reference is correct in code: "Model_Operators as Operators").

After digging in builder it seems that in lines 628-633 of Doctrine_Import_Builder

if (isset($definition['relations']) && ! empty($definition['relations'])) {
foreach ($definition['relations'] as $relation) {
$type = (isset($relation['type']) && $relation['type'] == Doctrine_Relation::MANY) ? 'Doctrine_Collection':$relation['class'];
$ret[] = '@property ' . $type . ' $' . $relation['alias'];
}
}

Here the $relation['class'] doesn't have full name, even though same key is used in lines 384-395:

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

if ( ! isset($relation['type'])) {
$relation['type'] = Doctrine_Relation::ONE;
}

if ($relation['type'] === Doctrine_Relation::ONE)\

Unknown macro: { $ret[$i] = " ".'$this->hasOne('' . $class . $alias . ''';\}

else {
$ret[$i] = " ".'$this->hasMany(\'' . $class . $alias . '\'';
}

When generating models like:

'pearStyle' => true,
'generateTableClasses' => true,
'classPrefix' => 'Model_',
'baseClassPrefix' => 'Base_',
'baseClassesDirectory' => 'Base',
'classPrefixFiles' => true

or

'pearStyle' => true,
'generateTableClasses' => true,
'classPrefix' => 'Model_',
'baseClassPrefix' => 'Base_',
'baseClassesDirectory' => 'Base',
'classPrefixFiles' => false

Produced files are like this:

Model_ModelName extends Base_ModelName
Base_ModelName extends Doctrine_Record
ModelNameTable extends Doctrine_Table

Problem is ModelNameTable class is not prefixed with "Model_" and thus cannot be autoloaded.

Doctrine Compiler recursively includes all the files it finds under Doctrine::getPath() location, which is the directory that contains Doctrine.php. In some cases it is convenient to put other libraries in the same directory, especially if they also use Zend Framework-like naming scheme. If including any of those files fails, for example because of parse error or not satisified dependency, to whole compilation fails.

The fix changes the directory traversed recursively to Doctrine::getPath().'/Doctrine', so the compiler does not try to include anything unrelated.

Doctrine_Export_Oracle::dropDatabase does not work, it contains some SQL errors. Here is the patch:

--- Doctrine-1.1.5/lib/Doctrine/Export/Oracle.php	2009-11-03 19:33:04.000000000 +0100
+++ doctrine/Doctrine/Export/Oracle.php	2009-11-06 14:40:46.000000000 +0100
@@ -76,17 +76,19 @@
         $sql[] = "BEGIN
 FOR I IN (select table_name from user_tables)
 LOOP 
-EXECUTE IMMEDIATE 'DROP TABLE '||I.table_name||' CASCADE CONSTRAINTS';
+EXECUTE IMMEDIATE 'DROP TABLE \"'||I.table_name||'\" CASCADE CONSTRAINTS';
 END LOOP;
 END;";
 
         $sql[] = "BEGIN
 FOR I IN (SELECT SEQUENCE_NAME, SEQUENCE_OWNER FROM ALL_SEQUENCES WHERE SEQUENCE_OWNER <> 'SYS')
 LOOP 
-EXECUTE IMMEDIATE 'DROP SEQUENCE '||I.SEQUENCE_OWNER||'.'||I.SEQUENCE_NAME;
+EXECUTE IMMEDIATE 'DROP SEQUENCE \"'||I.SEQUENCE_OWNER||'\".\"'||I.SEQUENCE_NAME||'\"';
 END LOOP;
 END;";

Scenario:

class User extends Doctrine_Record
{
public function setTableDefinition()

public function setUp()

}

Test:

//create User
$user = new User();
$user->username = 'Fabian';
$user->email = 'fabian@test.com';
$user->save();

...
...
// delete user
$user = Doctrine_Query::create()
->select('*')
->from('User')
->where("id=1")
->fetchOne();
$user->delete(); //this mark as deleted the user (delete_at field)

....
....

//create User with same data
$user = new User();
$user->username = 'Fabian';
$user->email = 'fabian@test.com';
$user->save();

// This throw error by the "unique"

File http://trac.doctrine-project.org/browser/branches/1.2/lib/Doctrine/DataDict/Sqlite.php

Contains undefined constant Doctrine_Core::ATTR_DEFAULT_TEXTFLD_LENGTH which breaks generation of sql for sqlite

Proposed fix: use $this->conn->options['default_text_field_length'] ?

Please see description posted on Doctrine's group:
http://groups.google.com/group/doctrine-user/browse_thread/thread/6cc308526e5ab075

Extra join condition get applied multiple times so i get error: 'SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens'

Problem seems to be related to change http://trac.doctrine-project.org/changeset/5550

What happens now is Doctrine_Query::_buildSqlFromPart() gets executed 3 times.
First time correctly with $ignorePending == false, second time correctly with $ignorePending == true and third time wrongly with $ignorePending == false.