Re: Managing EOF caching

Sun, 22 Jan 2006 20:44:45 -0800

Hey everyone,

I was just wondering about the validateForSave() method that Michael showed us and Art commented on ... I must admit I have, in the past, updated values in the validateForSave method without any problems, but after reading Practical WebObjects and some other online docs I have been scared to do so.  I know this is slightly off topic, but is it "okay" to update values in the validate method, such as a timestamp?  And why is it mentioned to be so "taboo" to do so?  All I've heard/read is that it can have serious side-effects, but no mention to what those side-effects actually are.

Thanks guys,
Michael.

On 19-Jan-06, at 5:53 PM, Art Isbell wrote:

You can actually add this code to your GenericRecord super class and add the column to all your tables on the fly, and defaulting the column to NULL if 3rd party applications are inserting into the database.  If 3rd party apps are updating other columns live, then you''ll have to keep those as locked columns anyway though.


    public void validateForSave() throws NSValidation.ValidationException ()

      if (dateLastUpdated()==null) setDateLastUpdated(new NSTimestamp());

... do rest of validation...

      }


I believe that the above code will update dateLastUpdated in EOs with no actual changes.  Any EO in which an attribute or to-one relationship has been set will be marked as updated even when the new values are identical to the old values.  No SQL would be generated normally, but because you have actually updated dateLastUpdated, the database will be needlessly updated.


To make this work correctly can be tricky and can depend on whether you are viewing this from the point of view of attributes and relationships or columns and foreign keys.


You need to examine updatedObject.changesFromSnapshot(editingContext.committedSnapshotForObject(updatedObject)).  If this is an empty dictionary, no actual changes have occurred, so dateLastUpdated shouldn't be updated.


If a to-one relationship value has actually changed, then updatedObject's foreign key value has also changed, so dateLastUpdated should be updated.


However, if only a to-many relationship array has changed, no SQL update statement for updatedObject will be generated because only foreign keys in relationship destination objects have been updated, so updatedObject.dateLastUpdated shouldn't be updated.  Others may consider updatedObject to be updated because one of its to-many relationships has been updated, so in this case, updatedObject.dateLastUpdated should be updated.  I take the former point of view.

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to