re: Core Data: is fetching safe during validateForInsert:/validateForUpdate?
re: Core Data: is fetching safe during validateForInsert:/validateForUpdate?
- Subject: re: Core Data: is fetching safe during validateForInsert:/validateForUpdate?
- From: email@hidden
- Date: Sat, 28 Mar 2009 08:28:55 -0400
Namaste!
This is off-list.
You know, I just went through this with the validateKey: bit. I found
that a side effect of fetching during that validateKey was the "save
all pending changes" "bug."
I then tried the performSelector, which worked, however, then the
validateKey was no longer getting used properly (I was working through
it to figure it out). That is, by using the performSelector, the
validateKey was bypassed and not in-line (which makes sense after
having thought about it). Boy, was that a bummer. I simply wanted to
keep the user from entering the same code for two things in an attempt
to help.
I'm still working out how to get around that mess - probably need to
keep some sort of global that contains a list against which to
compare. This is NOT the purpose of a database
unfortunately...anyway. For now I've simply commented out my validate
code.
In your case, though, I *think* the iClass example may be of help.
See the number generator class contained therein as it does what you
want (at least mostly).
I'd avoid fetching whenever inserting, saving, or some other operation
where you don't want to save stuff first, occurs.
Would be nice if fetching had an optional parm to NOT save first and
just deal with the current data...
Just my two cents.
Peace, Love, and Light,
/s/ Jon C. Munson II
Quoting Ben Trumbull <email@hidden>:
Is it OK to perform a fetch during validateForInsert:/
validateForUpdate:? I have a Core Data entity named 'Person' with an
attribute named 'uniqueNumber'. I want to ensure that no two People
have the same uniqueNumber.
It's not a great idea during validateForDelete: It fine during
validateForInsert or validateForUpdate so long as the awakeFromFetch
delegates and any other side effects (changes on the MOC or dirtying
MOs) of fetching eventually reach a quiescent state. The canonical
example of failing to do so is to update a timestamp in -willSave to
the current time. Blindly. Without checking if it's already set, or
equal. We'll save when the current time stops changing ...
- Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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