[TYPO3-mvc] @dontpersist

Martin Kutschker masi-no at spam-typo3.org
Sat Jul 17 18:21:58 CEST 2010


Am 16.07.2010 16:08, schrieb Franz Koch:
> Hey,
> 
>>> Performance is the one big thing. If I - in my hole plugin - don't want to persist things, I could
>>> save time by ommitting the persistAll() procedure.
>>> The other is usability of the model objects. Sometimes I want to do some stuff (like changing the
>>> tstamp before outputting or remove some children objects from a property's objectStorage). At the
>>> moment I have to clone the model objects for that to prevent the changes to be persisted. This costs
>>> additional memory and time as well.
>>
>> But why use an annotation for that? The use cases you describe look to me like run-time decisions.
>>
>> Anyway, assuming the framework would fetch you a private copy of the model so a) you can modify it
>> independently from other access and b) it won't get persisted, I think the identity map will hold a
>> copy of it and will give you a clone.
> 
> How would child objects be treated if persistence is deactivated for a object? Those would still be
> in the identity map and thus get persisted if altered.

Ah, things get complicated if you want something else as the framework's designers :)

I can think of two cases for "child" objects, though I think the term is misleading. Not every
reference to another object makes this a "child" (ie a dependent object). Anyway...

1) the "child" is fetched with the object (lazy or not)
2) the "child" is set with a setter

In case one is IMHO likely that in this case no persistence is required for the "child". I'm not
sure if this is clear for case two. I suggest that for 2) a clone is passed on to the setter, if no
persistence is required.

Masi

PS: IMHO there a cases when I want a disposable non-persisted clone of an object and cases when I
want a new persisted object based on another one. The latter case is IMHO the more logical effect
for a clone() operation. The former is a kind of hack that leads to all kind of hard questions like
"what about the relations". So I think one should create a simple value object () based on the
object for the view instead of obtaining a half-broken non-persisted object.


More information about the TYPO3-project-typo3v4mvc mailing list