Re: Managing EOF caching
Re: Managing EOF caching
- Subject: Re: Managing EOF caching
- From: Kieran Kelleher <email@hidden>
- Date: Mon, 23 Jan 2006 08:14:36 -0500
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.committedSnapshotForOb
ject(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:
email@hidden
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