On Feb 20, 2006, at 5:41 PM, Michael DeMan wrote:
Does anybody know if:
validateForSave() calls validateForInsert() if an object is not in the
database yet?
It works in the opposite direction for EOCustomObjects' default
implementation. From the API for ValidateForInsert:
Confirms that the receiver can be inserted in its
current state,
throwing an NSValidation.ValidationException if it
can't.
EOCUSTOMOBJECT'S IMPLEMENTATION SIMPLY
INVOKES VALIDATEFORSAVE.
The method validateForSave is the generic
validation method for
when an object is written to the external store.
If an object
performs validation that isn't specific to
insertion, it should go
in validateForSave.
I need to do some transaction oriented stuff and want to validate all
my object fields so I know its okay, execute a transaction on a 3rd party
system, then insert/save my object.
If you insert your EO into an EOEditingContext as it's created, then
"...do some transaction oriented stuff", validate your object fields, execute
a transaction on your 3rd party system and then do an
editingContext.insertObject() followed by
an editingContext.saveChanges(), there should be no problem.
I was thinking that calling validateForSave() before my 3rd party
transaction would work, but it seems to be calling validateForInsert()
somewhere.
The validateForSave method is appropriate here for generic validation
(i.e. validation not specific to insert, delete or update). The
validateForSave method of EOCustomObject, according to the API, does the
following:
Confirms that the receiver can be saved in its current
state,
throwing an NSValidation.ValidationException if it
can't.
EOCustomObject's implementation sends the receiver's
EOClassDescription a validateObjectForSave message,
then
iterates through all of the receiver's properties. If this
results
in more than one exception, the Exception returned contains
the
additional ones in its userInfo dictionary under
NSValidation.ValidationException.AdditionalExceptionsKey.
Subclasses should invoke super's implementation
before
performing their own validation, and should combine
any
Exception thrown by super's implementation with their
own.
Specifically,
when it says "... then iterates through all of the receiver's
properties." it means that for each class attribute xxx of your EO, it sends a
validateValueForKey("xxx") message to your EO which, by default, looks for a
method in your class of the form, validateXxx() and executes it.
I'm not 100% sure if it is, and if it is, whether that is the correct
behavior or whether I have some custom validation code that is causing it to
do that.
As Chuck suggested:
The easiest way to see is to add
this to validateForIinsert:
NSLog.out.appendln(new RuntimeException("backtrace"));
and then look at the
backtrace.
Regards,
Jerry