Re: Managing EOF caching
Re: Managing EOF caching
- Subject: Re: Managing EOF caching
- From: Michael Halliday <email@hidden>
- Date: Mon, 23 Jan 2006 08:26:12 -0500
Hi Kieran,
Yes, I am currently using the EOStateTransition stuff from Chuck's
book ... i was just curious as to what the actual side affects are to
updated values in validateForSave(). When I used to update values
such as dateLastModified etc, in the validate method I never had any
problems.
Thanks,
Michael.
On 23-Jan-06, at 8:14 AM, Kieran Kelleher wrote:
Not sure if this has been mentioned already, but instead of
updating values in validateForSave, then ERXGenericRecord (in
Project Wonder) subclasses can implement a willInsert, willUpdate,
etc. methods which will be called automatically before
validateForSave and in those ERXGenericRecord methods, you can
change values, update timestamps, generate custom codes, etc.
If you don't use Wonder, then you can implement Chuck's
EOStateTransition stuff (chapter 3) to achieve a similar result.
Regards, Kieran
On Jan 22, 2006, at 11:44 PM, Michael Halliday wrote:
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@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden