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: Aurélien Hugelé <email@hidden>
- Date: Mon, 12 Feb 2007 10:03:49 +0100
Michael,
Thanks for this precise answer.
On 11 févr. 07, at 23:27, Michael Jurewitz wrote:
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