[TYPO3-mvc] RFC #8244: Changes made to a domain object sitting at a "dirty" property won't get persisted

[Franz Koch]

Hey Jochen,

> On 2010-06-18, Franz Koch<typo3.RemoveForMessage at elements-net.de>  wrote:
>> crappy thunderbird :(
>
> Give slrn a try ;-)

I need a bit more GUI ;)

>> long story short: also +1 on testing, but with one remark. Now it could
>> happen that you run into endless recursions if you have self-references
>> of objects (just happened to me accidentally). So maybe we should add
>> some recursion prevention here before committing.
>
> Did you test it before and after applying the patch?


yes I did. Without the patch it worked just fine.

> It is complicated to fetch this kind of recursion because it can also be on a second (and third ...) level. IMO this is a general problem (like the circular dependencies in construcor injection). I am going to commit this patch and document this "trap". Or do you think this is a blocker?

And a protocol/stack/array storing the object hashes of already 
persisted objects might not be a solution for that?

--------------------
if (!in_array(spl_object_hash($queuedObject), 
$this->alreadyPersistedObjects) {
	$this->persistObject($queuedObject);
}
--------------------


As you're working on the persistObject stuff right now, I just noticed a 
partly redundancy. Have a look at lines 374-379, where the 
objectStorages get persisted. After a call to 
$this->persistObjectStorage(...) all contained items are looped and 
added to the persistence queue. But that's already partly done on lines 
520-531 inside the persistObjectStorage function, right? Shouldn't that 
be completely moved to the persistObjectStorage function?

-- 
kind regards,
Franz Koch