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