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 <trumb...@apple.com>:

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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/jmunson%40his.com

This email sent to jmun...@his.com



_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to