[Helma-dev] calling persist() on an already persistent HopObject

[Chris Zumbrunn]

On Nov 22, 2007, at 12:15 , Chris Zumbrunn wrote:

> On Nov 22, 2007, at 11:48 , Hannes Wallnoefer wrote:
>
>> The actual changes are performed on a non-persistent property. For
>> example, the onInit() function may parse the encoded object to
>> this.cache.custom. The application code would then work on
>> this.cache.custom, and since this is a non-persistent object/ 
>> property,
>> it wouldn't trigger the main object to be updated to the database.
>> Thus the need to call something like persist(), which would trigger
>> onPersist() to encode this.cache.custom back to the persistent
>> property and the resulting object to be stored to db.
>
> Thinking about this, makes me realize that I have the opposite  
> problem with my approach. If I deserialize a property in onInit and  
> set the property to the deserialized value, then it is marked dirty  
> and it will get serialized again by onPersist even if there was no  
> modification. Hmm... having to use this.cache to work around that  
> isn't very elegant.

...or maybe not...: If onInit modifies a property of that hopobject,  
does the hopobject get marked dirty? Either way, wouldn't it make  
sense to be able to opt-in/opt-out of that in the context of onInit?

In other words, with the new behavior of persist(), we have the  
ability to opt-in. Do we also need the ability to opt-out? If so, that  
might change where to best place that functionality. For example, we  
have isClean() and isModified(). So how about isClean(true) and  
isModified(true). But we also already have isInvalid() and  
invalidate() as a method pair, so that wouldn't be consistent either.

Sorry for blabbing, I'm obviously just thinking out loud.

Chris