Re: [CORE DATA] is it safe to modify/delete a managed object during its validation?
Re: [CORE DATA] is it safe to modify/delete a managed object during its validation?
- Subject: Re: [CORE DATA] is it safe to modify/delete a managed object during its validation?
- From: Michael Jurewitz <email@hidden>
- Date: Sun, 11 Feb 2007 14:27:06 -0800
On Feb 8, 2007, at 3:26 AM, Aurélien Hugelé wrote:
Hi list!
I've finally implemented some more validation in my managed object
subclass, in validateForUpdate: and validateForInsert:
If problem is encountered, is is possible to fix the object on the
fly at this place? can I use accessors to modify the object?
Since the validation phase is processed at the beginning of the
save phase, will the changes (made during validation phase) be
applied for THIS save?
thanks
Hi Aurélien,
From the Core Data Programming Guide:
It is important to note that the input value is a pointer to object
reference (an id *). This means that in principle you can change the
input value. Doing so is, however, strongly discouraged, as there are
potentially serious issues with memory management (see Key-Value
Validation in Key-Value Coding Programming Guide)
If you change the input value in a validate<Key>:error: method, you
must ensure that you only change the value if it is invalid or
uncoerced. The reason is that, since the object and context are now
dirtied, Core Data may validate that key again later. If you keep
performing a coercion in a validation method, this can therefore
produce an infinite loop. Similarly, you should also be careful if
you implement validation and willSave methods that produce mutations
or side effects—Core Data will revalidate those changes until a
stable state is reached.
While the Key-Value Programming Guide provides some background for
why changing the value may potentially create memory management issues:
Since validation methods can replace both the original value object
and the error object that are passed by-reference, care must be taken
to ensure proper memory management. Your application must ensure that
objects that it creates and passes as parameters to the validation
method have been autoreleased before invoking the method.
As an example, the code in Listing 4 invokes the validateName:error:
method that was shown in Listing 2. It creates the newName object,
and passes it to the validateName:error: method without autoreleasing
the object. However, because the validation method replaces the
object that newName references, when the newName object is explicitly
released, the validated object is released instead. This causes two
problems. Attempting to access the validated name value later will
cause a crash, because the object that is retained by the
setValue:forKey: has been released, and the name object passed to the
validateName:error: method leaks.
Note that while it is OK to change the value passed into a validation
method by substituting your own value there are several very
important points to keep in mind. You must be sure that the object
you use to substitute is autorealeased. Further, you must be sure
that you do not release or autorelease the original value object that
is passed in to the validation method via the id *.
Moreover, be aware that changing the value inside the validation
method will cause the object to need to re-validate. This can be
potentially expensive.
-Michael Jurewitz
/*****************************************
Apple DTS Engineer
Cocoa - Core Data - Bindings
Save the Date.
WWDC 2007 | June 11-15, San Francisco
http://developer.apple.com/wwdc
email@hidden
*****************************************/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden