Validation exception thrown only if internal nesting level == 1

Additional information: On doctrine 1.1.x the exception is thrown without this modification.

It seems, the problem is the counter of internal nesting level. I output these member variables:

Doctrine 1.1.2

Doctrine_Transaction::commit invalid is not empty - internal nesting level: 1 nesting level: 2

ok 1 - Article cannot be created if empty: Doctrine_Validator_Exception: Validation failed in class Article

  1 field had validation error:

    * 1 validator failed on slug_title (notnull)

Doctrine 1.2.2

Doctrine_Transaction::commit invalid is not empty - internal nesting level: 0 nesting level: 1

not ok 1 - Empty Artcile could be created!

Yeah! I found the reason:

I attached a template (listener) into my model which validates the body and this method call:

// ...
if ($obj->getAuthor()->getAge())  # this creates new empty Author object
{
  // ...
}
// ...

On Doctrine 1.1, the method saveGraph() of class UnitOfWork executes first saveRelatedLocalKeys and then the hooks methods (preSave, etc.) and my code works!

On Doctrine 1.2, the method saveGraph() call *first* the hooks method and then the saveRelatedLocalKeys which save the empty author object and then destroy the internal nesting level
and the validation exception is not thrown.

Workaround for my listener:

// ...
if ($obj->relatedExists("Author") && $obj->getAuthor()->getAge())  # relatedExists() needed to avoid create empty Author object
{
  // ...
}
// ...

What do you think: It's a bug or a feature?

A test case attached to reproduce the bug.

The test passes if you remove the custom save() method of Ticket_DC676_Author class.

The problem: default "foobar" modifies the Author and is modified. Doctrine tries to save it,
but because there is more than two transactions, the validation exception is not thrown for Article object.

Something that really helps with determining what we should do is to find the exact changeset that causes the behavior. If we can look at what code was changed, we can then understand better what to do.

This changeset affects the problem:
http://trac.doctrine-project.org/changeset/6126/branches/1.2/lib/Doctrine/Connection/UnitOfWork.php

But I really don't like this logic how the validation exception is handled. I would seperate these things:

The method validate() should throw exception, and the method commit() should commit only if model is valid and nothing more.

1. go recursive into the model and call the validate() method

2. if not valid, exception is thrown

3. elseif ok, commit is called

PS. Sorry for late answer: I had a lot of work ...

Do you see something with that commit that could be changed that fixes your issue?

Whoops. This change is causing some problems. It causes lots of tests to fail in our test suite. Reverting for now. Can you try your change against our test suite and see if you can determine anything? Thanks, Jon