Ideal Key Attribute for Cross-Store Fetched Objects
Ideal Key Attribute for Cross-Store Fetched Objects
- Subject: Ideal Key Attribute for Cross-Store Fetched Objects
- From: John Bishop <email@hidden>
- Date: Fri, 24 Mar 2006 14:45:38 -0600
I have a Core Data multi-store environment (imagine a store full of golfers
and a store full of their scorecards) in which a golfer's scorecards would be
identified with a fetched property (imagine "[golfer scorecards]"). I need a
key representing the golfer in the scorecard store to do this fetch, and it
seems that perhaps the golfers [[objectID URIRepresentation] description]
would be a good choice, since it's unique for each golfer, retrievable easily
(and just once for the fetch, I think), etc. But maybe I'm missing something.
Here are a couple things that could be problems:
1. When the scorecard data is stored with the golfer's ID, there would be a
problem if the golfer wasn't yet in the persistent store - ie, its ID was
temporary and no good for later comparison. I'd have to handle cases where
the golfer "isInserted" specially - or prohibit them.
2. The golfer's object ID/URI/description is a fairly long complex string, and
comparison might take longer than necessary because the first umpty-ump
characters of EVERY golfer's ID (and the matching attributes in EVERY
scorecard) are the same (encoded to refer to the store).
3. In any case in which the golfer might be deleted from its store (whether or
not later replaced), all those scorecards are hanging with IDs for a
non-existant golfer. (I understand the requirements I'd face if I wished to
"cascade delete" scorecards on deletion of a golfer.) This particular issue
doesn't bother me much - I foresee the stores being usable separately, so I'd
have this problem even if Core Data allowed cross-store relationships.
Cross-store sample code, like iClass and others, illustrates cross-store
fetches with stuff like studentName, teacherName, or compound predicates in
the fetch. That "feels" like it would quickly fail with large amounts of data
(students and teachers with duplicate names, names as keys when the name might
change, etc.).
Finally, my question of the list: Can anyone comment on the practice of using
objectIDs as keys for cross-store fetches, and if not appropriate, is there a
better alternative?
Thanks,
John
------------------------------------------------------------------
John Bishop <mailto:email@hidden>
Mulligan Software <http://www.mulligansoftware.com>
Mulligan's Golf Personal - Stats & Handicapping for the Mac Golfer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden