I think I can best explain what is happening with the following code:

// Create some object in the database.
$instance = new Model();
$instance->field = "value 1";
$instance->save();
$id = $instance->id;

$table = Doctrine::getTable('Model');

// Load the object from the database.
$instance_a = $table->find($id);

// Modify a field. 
$instance_a->field = "value 2";
print $instance_a->field . "\n";     // prints "value 2";
print_r($instance_a->getModified()); // prints "field"

// Load the object again from the database, into a new variable.
$instance_b = $table->find($id);

// $instance_a and $instance_b now are the same object.
// The data is fresh data from the database.
print $instance_a->field . "\n"; // prints "value 1";
print $instance_b->field . "\n"; // prints "value 1";

// However, the modified field list was not reset.
print_r($instance_a->getModified()); // prints "field"
print_r($instance_b->getModified()); // prints "field"

So the fresh record from the database is incorrectly marked as dirty. Main result is that this will trigger database activity when saving a model to the database, while no field data was actually changed.

Missing ; in saveCache() function and delete method should also be named deleteCache as in other drivers.
This prevents xcache driver from working as well as compiling Doctrine to single PHP file. Patch included to fix the issue.

Fatal error: [] operator not supported for strings in /opt/httpd/lib/php/Doctrine/Cache/Driver.php on line 244

The fetch function return a string, not a array

I offer following modification :

File: Doctrine/Cache/Apc.php

public function fetch($id, $testCacheValidity = true)

batchUpdateIndex leaks memory when indexing a table. It holds onto a copy of every row it indexes in memory. I've attached a patch that fixes this issue.

I have implemented a very small - and unobtrusive - change to Doctrine_Migration_Base that enables users to set application-level default table options for Doctrine_Migration_Base::createTable().

I implemented this change some time ago in a custom migration class. I wanted my migrations to always create INNODB and UTF-8-ready tables without having to always specify options. I blogged about it and others were interested.

In your boot script - for example - set default table options like:

Doctrine_Migration_Base::setDefaultTableOptions(array(
'type' => 'INNODB',
'charset' => 'utf8',
'collate' => 'utf8_unicode_ci',
));

The enclosed patch, which includes tests, was created against 1.2 r6535.

Thanks

With the current code, the return data is outside the method's documentation for @return and there will be a notice from PHP about $result being undefined.

Fixed with the following patch.

    public function nextId($seqName, $onDemand = true)
    {
        $sequenceName = $this->conn->quoteIdentifier($this->conn->formatter->getSequenceName($seqName), true);

        $query = "SELECT NEXTVAL('" . $sequenceName . "')";
        try {
            $result = (int) $this->conn->fetchOne($query);
        } catch(Doctrine_Connection_Exception $e) {
            if ($onDemand && $e->getPortableCode() == Doctrine::ERR_NOSUCHTABLE) {

                try {
                    $result = $this->conn->export->createSequence($seqName);
                } catch(Doctrine_Exception $e) {
                    throw new Doctrine_Sequence_Exception('on demand sequence ' . $seqName . ' could not be created');
                }
                return $this->nextId($seqName, false);
+           } else {
+             throw new Doctrine_Sequence_Exception('sequence ' .$seqName . ' does not exist');
            }
        }
        return $result;
    }

We need better control for setting the hash/key for resultset cache entries. Then provide a way to clear these cache entries.

http://trac.doctrine-project.org/ticket/2042

$temp = Doctrine_Query::create() 
->from('Profile p') 
->where('p.id=?', $o) 
->setHydrationMode(Doctrine::HYDRATE_ARRAY) 
->useResultCache(true, 3600, 'product_cache') // custom tag 
->execute(); 

$temp = Doctrine_Query::create() 
->from('Model m') 
->setHydrationMode(Doctrine::HYDRATE_ARRAY) 
->useResultCache(true, 3600, 'product_cache') // custom tag 
->execute(); 

$temp = Doctrine_Query::create() 
->from('News n') 
->setHydrationMode(Doctrine::HYDRATE_ARRAY) 
->useResultCache(true, 3600, 'news_cache') // custom tag 
->execute(); 

and now

$conn  = Doctrine_Manager::getConnection('sqlite_cache_connection'); 
$cacheDriver = new Doctrine_Cache_Db(array('connection' => $conn, 
'tableName' => 'cache')); 

$cacheDriver->deleteByTag('product_cache');

I always use this counstructions for get mysql current time:

example:
$us = Doctrine::getTable ( "Users" )->find ( 1 );
$us->currentlogin = new Doctrine_Expression('NOW()');
$us->save();

but after update to new version this DONT work!

The following yml schema will result in a table with the integer field marked as not null

MyTable:
columns:
intfield:
type: integer
notnull: false

I have traced this back to line 244 in the getIntegerDeclaration function in lib/Doctrine/DataDict/Mssql.php

$notnull = (isset($field['notnull']) && $field['notnull']) ? ' NOT NULL' : '';

should be

$notnull = (isset($field['notnull']) && $field['notnull']) ? ' NOT NULL' : ' NULL';

This fixes the issue for us and hasn't created any problems thus far.

If the name of ForeignKey constraint is too long, the sql insert failed on this.

I tested with this:
ALTER TABLE article_i18n_index ADD CONSTRAINT article_i18n_index_id_article_i18n_id FOREIGN KEY (id) REFERENCES article_i18n(id) ON UPDATE CASCADE ON DELETE CASCADE;

The article_i18n_index_id_article_i18n_id <-- this is too long

MySql 5.086
Doctrine 1.2 (last)

Although I know the Class Table Inheritance code is unsupported it is somehow working good enough for me to use this feature anyway.

There is however a bug in the code when not defining column values on the parent object, which the attached small patch solves.

Could this be added before the 1.2 release ? Thanks

This patch change the sign . to _ into the name of foreignKey because the name isn't valid with dot in the name.

You can set the boolean option 'classPrefixFiles' to false when generating models to prevent the full class name becoming your file name. However, you this option has no effect on generated base classes. So even if you have set 'classPrefixFiles' to false, the generated files with base classes still contain the base class prefix name in their file name.

I suggest having a 'baseClassPrefixFiles' options OR following the 'classPrefixFiles' option for base class file names as well.

This is how the generated file names ended up in my models folder (with 'baseClassPrefix' = 'Base_'; 'classPrefixFiles' = false; 'baseClassesDirectory' = 'Base' and 'baseClassPrefixFiles' = false):

./Base/Base_Monkey.php
./Monkey.php

Should be:

./Base/Monkey.php
./Monkey.php

Currently its not possible to generate base classes that are compatible with the PEAR file/class naming conventions
user -> user.php
base_user -> base/user.php

The following settings do not give the desired results
         baseClassPrefix: "base_"
        baseClassesDirectory: "base"

This seems like a very surprising, yet critical omission, which forces a symfony style autoloader instead of the Doctrine native autoloader.

When importing a db table as a model, we see the following for a boolean field:

        $this->hasColumn('is_blocked', 'boolean', 1, array(
             'type' => 'boolean',
             'length' => 1,
             'fixed' => false,
             'unsigned' => false,
             'notnull' => true,
             'default' => 'false',   // <----- this field not 0, 1 or a boolean, but a string literal linstead
             'primary' => false,
             ));

Creating an object and immediately saving it results in two validation errors for this field:

1. The field is not boolean, but string
2. The field is not length 1, but length 5 (string "false")

I applied the following patch to the listTableColumns() function:

            elseif (preg_match("/^'(.*)'::character varying$/", $description['default'], $matches)) {
                $description['default'] = $matches[1];
            }
+           elseif ($description['type'] == 'boolean') {
+               if ($description['default'] === 'true') {
+                   $description['default'] = true;
+               } elseif ($description['default'] === 'false') {
+                   $description['default'] = false;
+               }
+           }

            $columns[$val['field']] = $description;

This makes the import work as expected for us.

The Doctrine.php class makes it very hard to pull in Doctrine via svn:externals in combination with an existing autoloader. The problem is the Doctrine.php this means you usually end up with something like Doctrine/Doctrine.php locally, which means you need to use the Doctrine autoloader or add another include path.

One solution is to simply do two externals:
http://svn.doctrine-project.org/branches/1.2/lib/
http://svn.doctrine-project.org/branches/1.2/lib/Doctrine

And then including Doctrine.php manually.
The issue is of course that I cannot just do an external on the file because those only work on local repos. Svn also does not support sparse checkouts for externals.

I see 2 solutions:
1) Simple solution would be to provide a directory with just Doctrine.php via a separate url
2) Move the code in Doctrine.php to Doctrine/Core.php and just extend that class from Doctrine.php for BC

We are generating our entity classes from the database. By doing so, we get a nicely separated set of base record classes and derived record classes where we can implement our logic. The case is, that we want to add validators to about every field there is. The only way that we can do that right now, is by overriding the setUp() method, calling parent::setUp() and providing new column definitions using addColumn(). By doing so, we do have to include the options that were so nicely automatically determined from the database. If we now update our schema in the db and regenerate the base record classes, we might have to manually update addColumn() calls in derived records.

To make it possible to fully separate the automatic and manual code, we were looking for a method to tweak an already existing table, but we couldn't find such method. Therefore, we implemented one ourselves.

A practial usage example. This is what we had to write in the derived class (not a validator example, but the idea is the same of course: tweak or add a column option):

    // Override the "info" column definition. We want this field to be
    // an object field, so we can store a serialized object in it.
    $this->hasColumn('info', 'object', null, array(
      'type' => 'object',
      'fixed' => false,
      'unsigned' => false,
      'notnull' => true,
      'primary' => false,
    ));

This is what we write now:

    $this->setColumnOption('info', 'type', 'object');

Please, consider adding the proposed change from the attached diff file. Of course, also let me know if there is a better way to handle this.

From the setColumn() function in Doctrine_Table:

        // extract column name & field name
        if (stripos($name, ' as '))
        {
            if (strpos($name, ' as')) {
                $parts = explode(' as ', $name);
            } else {
                $parts = explode(' AS ', $name);
            }

Because strpos($name, ' as') is missing a space after "as", there is a (I admin, quite rare case that this might fail, namely a case like "ArchiveStatus AS as". This would match the case sensitive ' as' check and it would then split on ' as ', resulting in breakage.

The problem is concerned about sqlite driver. Currently in every occurence of "NOW()" in where clause PDO substitutes result of PHP time() function. Here is a cause:

            $this->dbh->sqliteCreateFunction('now', 'time', 0);

Unfortunatelly, sqlite expects a datetime value rather then integer timestamp.

In result, every occurence of 'now()' in where clause is treated as '0'.

I have prepared a testcase and patch.

Hello,

Currently if within a single migration class one uses the automation methods $this->table() and $this->foreignKey() the process will fail when moving down because the system will execute the down direction in the same order as the up direction. For example:

public function migrate($direction) {
$this->table($direction, 'mytable', ...);
$this->table($direction, 'myrelatedtable', ... );
$this->foreignKey($direction, 'mytable', 'myfkname', ...);
}

Going up, everything is fine. The tables are created and the FK is applied. Going down, however will error out since by the time the FK is going to be removed the table it belons to is gone.

Doctrine currently doesn't support conditional unique keys. One commonly happening situation is when we have a model with a column (eg. named "deleted") indicates whether the record was deleted and should no longer be treated as active. If we have an unique index on a "name" column, the index should contain only records with deleted = false. It also concerns an unique validation.

I have prepared a patch for Doctrine_Validator_Unique and Doctrine_Export_Pgsql (Postgresql natively supports conditional indexes).

Example of usage:

public function setTableDefinition()
{
  $this->hasColumn('id', 'integer', 4, array('primary' => true, 'autoincrement' => true, 'sequence' => 'model_id_seq'));
  $this->hasColumn('name', 'string', 128, array('notnull', 'unique' => array('where' => 'deleted = false')));
  $this->hasColumn('deleted', 'boolean', 1, array('notnull', 'default' => false));
  $this->index('model_unique_name', array('fields' => array('name'), 'where' => 'deleted = false', 'type' => 'unique' ));
}

When creating two related models and saving the main one to the database, both models get stored in the database. That is expected behavior. Now, when one of the two models has a validation problem and I call save() on it - without first linking it to the other model - I get a Doctrine_Validator_Exception. That is expected behavior. Now (patience, we're getting to the bug now), when one or both of the models has a validation problem and I link them prior to saving them, I don't get a Doctrine_Validator_Exception, but instead a database level exception Doctrine_Connection_Pgsql_Exception. That is unexpected behavior.

One wouldn't notice this issue when doing code like:

  try {
    $object->save();
  } catch (Exception $e) {
    // .. handle the exception
  }

However, code like we are using it in our project more often looks like this:

  try {
    $object->save();
  } catch (Doctrine_Validator_Exception $e) {
    // .. handle the validation exception
  } catch (One_Of_Our_Exception $e) {
    // .. handle our exception
  } catch (Exception $e) {
    throw $e; // unexpected exception, re-throw and pray 
  }

In the attachment you find a test.yml and a test.php that I used for figuring out the behavior. Here's the output from running the test script:

1. OK, got expected exception
2. OK, record A saved
3. OK, got expected exception
4. OK, record B saved
5. OK, record A saved with a linked record B
6. Error: unexpected exception was thrown.
   Type: Doctrine_Connection_Pgsql_Exception
   Message: SQLSTATE[23502]: Not null violation: 7 ERROR:  null value in column "b_id" violates not-null constraint
7. Error: unexpected exception was thrown.
   Type: Doctrine_Connection_Pgsql_Exception
   Message: SQLSTATE[23502]: Not null violation: 7 ERROR:  null value in column "a_id" violates not-null constraint
8. Error: unexpected exception was thrown.
   Type: Doctrine_Connection_Pgsql_Exception
   Message: SQLSTATE[23502]: Not null violation: 7 ERROR:  null value in column "a_id" violates not-null constraint

Inspecting the Connection/UnitOfWork.php code, I see that saveGraph() calls $isValid = $this->insert($record). Now, when insert() sees that the record is invalid, it returns a false value. Somewhat later this results in calling $conn->transaction->addInvalid($record) to register the problem. At the end of the code block, I find (around line 126):

                // save the MANY-TO-MANY associations
                $this->saveAssociations($record);

That is the point where things break. Even when an associated record does not validate, saveAssociations() will be called, resulting in a db level error about a reference id not being set (logical, since the related record was not saved and did not get an id assigned to it).

In my opinion, this shouldn't happen, but I'm only using Doctrine for one day, so if I am missing some important piece of knowledge or documentation here, then please let me know.

I'm a fan of the CLI and tasks in Doctrine, but I recently had some trouble registering custom tasks.

Having spent a good while refactoring this weekend, I understand that you can load additional tasks from a particular directory. Unfortunately, the tasks in said directory must follow the Doctrine naming conventions (i.e. they must start "Doctrine_Task").

I'm using Doctrine 1.1.4 on PHP 5.3 and am using namespaces. Ideally, then, I don't want to have to follow the Doctrine naming conventions: I want to be able to use my own.

Here's an example of what I can now do with my patched version:

$cli = new Doctrine_Cli($config);
$cli->registerTask('sakura\installer\doctrine\GenerateModelsDb', 'sakura-generate-models-db');
$cli->run($_SERVER['argv']);

I have also implemented a public loadAndRegisterTask() method that will load a specified file and then register a class.

In refactoring Doctrine_Cli, I've written a test case, Doctrine_Cli_TestCase, which reasonably thoroughly tests the new and some of the old functionality. There's still scope for some more refactoring and testing, but I've got what I need for now.

The enclosed patch was created against the 1.1.4 tag.

Best regards

The Doctrine_Record_Listener_Interface is no longer up to date with the code base. The code base expects the listener to implement a getOption method which is not available on my listener models... See the patch file.

... or there should be a "baseClassPrefixFiles" option.

I've set the priority of this ticket to minor, but I'd really like this to be implemented so that I don't have to rename files after generating them.

For example, for a foreign key from user.group_id -> group.id in a schema "main" - with explicite specified the schema name in the table names (main.user, main.group) - Doctrine generates a constraint name "main.user_group_id_main.group_id". Unfortunately, "." is reserved char and is illegal in a constraint name.

Recently I had a model where I needed a custom unique slug instead of a slug which is built from fields.

At first I thought that maybe the "builder"-option was there for that purpose but soon I realized that this is obviously not the right one.

The only left option was that I would need to create the method "getUniqueSlug" in the record class. This is of course an option and has its uses but with it you would have to reimplement the collision detection for uniqueness again which are already implemented in the getUniqueSlug-method of the sluggable class.

After reading the code several hours I came to the conclusion that this functionality is simply missing so I created a new option called "provider" which is a callback. This callback provides the equivalent of the concatenation of the table fields. The great thing about this is that you don't have to care for uniqueness or the proper urlized format because this is still taken care of by the sluggable behaviour. Thus this patch is very unobtrusive and completely backwards-compatible of course.

Usage is pretty straight-forward:

model:
  actAs:
    Sluggable:
      provider: [modelTable, provideSlug]

Or whatever you want to name the method which is called.

jwage responded in trac:

This is already possible if you just implement a toString() method and don't specify any fields.

But I have to disagree. If I use toString() I still have to care about the uniqueness of the slug by myself because only when fields are specified this gets called inside the code:

$this->getUniqueSlug($record, $value);

Otherwise only the builder-function is called.

So atm this is NOT possible.

If we follow the logic that Base models are auto generated and we extend in improve them in our "main" models, then its also necessary to control validators. We shouldnt not manually specify them in Base models, so there should be a way to control them.

I have written a simple function which sets validators for field/fields.