TYPO3.Flow

in the repository updating is done like
1if ($this->persistenceManager->getIdentifierByObject($existingObject) !== NULL) { 2 $this->persistenceManager->replaceObject($existingObject, $newObject); 3 [...]

in the replaceObject() method.
But the repository also keeps track of added and removed objects.

Maybe we need to work with a custom SplObjectStorage like in Extbase?

No update needed. If you change a persisted object (attached to anything persisted), changes are picked up automagically. No need for an update. If that does not work it's a bug, but we don't need anything new here!

Karsten Dambekalns wrote:

No update needed.

How would you solve this:

1public function updateAction(Comment $comment) {
2  ...
3}

usually you would do $this->commentRepository->update($comment);
So I'd expect something like $post->update($comment);

FYI i solved this for now by introducing following method to the abstract base controller:

 1/**
 2 * Replaces an existing object with the same identifier by the given object
 3 *
 4 * @param object $modifiedObject The modified object
 5 */
 6public function update($modifiedObject) {
 7    if ($modifiedObject->FLOW3_Persistence_isClone() !== TRUE) {
 8        throw new \F3\FLOW3\Persistence\Exception\IllegalObjectTypeException('The object given to update() was not a clone of a persistent object.', 1298540772);
 9    }
10    $uuid = $this->persistenceManager->getIdentifierByObject($modifiedObject);
11    if ($uuid === NULL) {
12        throw new \F3\FLOW3\Persistence\Exception\UnknownObjectException('The "modified object" does not have an existing counterpart in this repository.', 1298540861);
13    }
14    $existingObject = $this->persistenceManager->getObjectByIdentifier($uuid);
15
16    if ($this->persistenceManager->getIdentifierByObject($existingObject) === NULL) {
17        throw new \F3\FLOW3\Persistence\Exception\UnknownObjectException('The "existing object" is unknown to the persistence backend.', 1298540871);
18    }
19    $this->persistenceManager->replaceObject($existingObject, $modifiedObject);
20}

I would agree with Karsten here: no change needed. Otherwise it would break the aggregate boundaries and thus the idea of atomic domain transactions. There are two options to handle an incoming Comment:

1. find the corresponding Post (through a method of the PostRepository) and update the Comment through a public function of this Post, or
2. treat the Comment as Aggregate Root and implement a CommentRepository (Comment Aggregates within a Post Aggregate doesn't break anything IMO).

Jochen Rau wrote:

I would agree with Karsten here: [...]

[...] update the Comment through a public function of this Post

How? That was the point of this issue ;)
Of course my "solution" is just a hack to get it working for me. We needed s.th. like $this->comments->update($modifiedComment); but SplObjectStorage can't do that obviously..
We probably need a specialized "entity collection" that extends SplObjectStorage and knows how to find the original object by the modified clone..

In theory update() should take care of that. It recursively checks for entities that are clones and should update/replace them as well.

Karsten Dambekalns wrote:

In theory update() should take care of that. [...]

..but there is no update() in \SplObjectStorage ;)

The correct solution when taking the domain model into account would be to fetch the Post the comment is attached to and map the new values onto the Comment referenced by this Post. In other words: the problem is that the comment is completely detached from it's surroundings in this scenario...

After digging a bit deeper into this issue, here my findings:
The problem seems to be that \Doctrine\Common\Persistence\ObjectManager::contains() returns FALSE for a cloned object!?
\Doctrine\ORM\UnitOfWork::getEntityIdentifier() returns a UUID instead of the expected identitye (array('title' => 'Location Title')).

For now, i fixed it in the Conference package by writing:

1$this->persistenceManager->merge($modifiedObject);

But I think, that the framework should handle $this->conference->setLocation($modifiedLocation) automatically..

Karsten Dambekalns wrote:

[...] the title is part of the identity, and changing this is non-trivial at best.

I see, but do you have a idea/suggestion on how to solve this? Or do we have to revert the models to use a uuid column?

With the new persistence behavior this should be solved, check!