Feature #30933

Check for unique constraints on add()

Added by Thomas Hempel almost 10 years ago. Updated almost 7 years ago.

Needs Feedback
Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Has patch:


If you define a uniqueConstraints in a Model you want to have that checked as soon as the add() method of your repository is called. If you don't do that it might lead into some problems later in your controller.

For example you have the following model:

 * @scope prototype
 * @entity
 * @Table(name="acme_demo_domain_model_mymodel", uniqueConstraints={@UniqueConstraint(name="name_idx", columns={"name"})})
class MyModel {
     * @var string
    protected $name;


The propety name has a doctrine unique contraints which means that i can only exists once in the database.

Now you have this controller

class AcmeDemoCommandController extends \TYPO3\FLOW3\MVC\Controller\CommandController {

     * Add a MyModel
     * Adds a MyModql with a given name
     * @param string $name The name of the repository
     * @return void
    public function addCommand($name) {
        try {
            $newModelInstance = new \Acme\Demo\Domain\Model\MyModel($name);
        } catch (\Exception $e) {
            $this->outputLine('The MyModel could not be created!');
            return -1;

        $this->outputLine('New MyModel was created.');


On the command line you do the following:

./flow3 AcmeDemo:add foo

This works the first time as expected.

When you execute it the second time, you get an Exception because the name "foo" is already present in the database. You get the Exception even though you put the code in a try catch blog is, this is because the method to actually save the changes is called after your code. The responsible method is persistAll().

This leads to some more problem which I put into a seperate issue. For now let me tell you that it doesn't work.

It would be really cool if the add would return something that tells me if an object can be persisted or not. Otherwise I had to check all my DB constraints manually whenever I work with my model. And if I understood DDD corectly, this is not the Domain of my controller. ;-)

Related issues

Related to TYPO3.Flow - Bug #30934: persistAll() should only be called if EntityManager is still aliveResolvedKarsten Dambekalns2011-10-14

Related to TYPO3.Flow - Feature #29547: @identity should make property unique in DatabaseResolvedChristian Müller2012-04-30

Related to TYPO3.Flow - Bug #32823: Make combination of Account identifier and authentication provider name globally uniqueResolvedRens Admiraal2011-12-23


Updated by Karsten Dambekalns almost 10 years ago

  • Tracker changed from Suggestion to Feature
  • Project changed from TYPO3 Flow Base Distribution to TYPO3.Flow

Updated by Karsten Dambekalns almost 10 years ago

  • Category set to Persistence

Updated by Christopher Hlubek almost 10 years ago

  • Has patch set to No

This is actually a problem with the FLOW3 persistence approach since some time. At one side it's an advantage to not save the object in "add" and defer it until the end. Otherwise (especially for things like Uniqueness or DB constraints) it fails much too late to respond to this in a nice way.

I wouldn't change the behaviour of add since it allows for a nice caching of operations. But we could make a persistAll() or similar operation more user friendly to provide results for persistence operations object-wise (like results for validations for example).


Updated by Karsten Dambekalns over 9 years ago

Actually moving the validation run from onFlush to prePersist / preUpdate could solve this. Worth a try.


Updated by Gerrit Code Review over 9 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/8733


Updated by Karsten Dambekalns over 9 years ago

  • Assignee set to Karsten Dambekalns
  • Target version set to 1.1

Updated by Robert Lemke over 9 years ago

  • Status changed from Under Review to Needs Feedback

Updated by Robert Lemke over 9 years ago

  • Target version deleted (1.1)

Updated by Christian Müller almost 7 years ago

This change is still relevant and needs to move to jira.

Also available in: Atom PDF