Re: Fetch Requests on Non Standard Classes in Core Data
Re: Fetch Requests on Non Standard Classes in Core Data
- Subject: Re: Fetch Requests on Non Standard Classes in Core Data
- From: Quincey Morris <email@hidden>
- Date: Thu, 14 May 2009 23:23:16 -0700
On May 13, 2009, at 20:41, Ian Peters-Campbell wrote:
I'm fairly new to iPhone/Cocoa, and brand new to Core Data. I'm in
the
process of writing a data manager, and I would like it to use Core
Data.
Unfortunately my brain is breaking a little bit with a conceptual
issue. I
need an entity which will store some binary data along with a guid
(a 16
byte int) for indexing/lookup. This in itself is a little bit
harrowing,
since I don't see any native support for 16 byte ints in Core Data.
To make matters worse though, the guid is wrapped in what is
effectively a
container class which includes network serialization functionality, an
isEqual method, etc along with the 16 bytes of guid data. If
possible I
would like to store the wrapper object in Core Data rather than
extracting
data from it and then rebuilding it each time I store/retrieve the
object.
It seems eminently possible to do the actual storage/retrieval using
an
NSValueTransformer with a Transformable attribute, but what is
hurting my
brain is the idea of lookups. How (if at all) can I store these
wrapper
objects in such a way that I can do fetch requests based on their
internal
values?
That is, if I have an object:
wrapperA:
guidBytes "1111222233334444"
And I have already stored two entities in Core Data with something
like
EntityInstanceA:
binaryData: foo
accessDate: bar
guidInstance:
guidBytes: "1111222233334444"
EntityInstanceB:
binaryData: baz
accessDate: quz
guidInstance:
guidBytes: "4444333322221111"
Is it possible for me to do a fetch request using the guidBytes inside
wrapperA to return me EntityInstanceA with its matching guidBytes,
which are
stored as a member of a class which is "blobbed" into an entity
attribute?
I think you have several viable options here, although the answer will
depend on the total number of objects involved. If it's not too large,
then even the solution of duplicating the stored data isn't terrible.
Another option is to store the guid as a string in the persistent
store (and use that for your fetches), but to implement the 16-byte
guid data as a transient NSData attribute that's calculated from the
string when you insert or fetch an object. (No value transformer is
required if you keep the bytes in a 16-bye NSData object.) That way
you wouldn't waste as much space in the persistent store.
Or, since you appear (from your description) to be using these guid
values as an ad-hoc implementation of relationships between objects,
you could create actual Core Data relationships instead. For example,
instead of your wrapperA object having a guidBytes attribute, it could
have a 1-1 EntityInstance relationship, which is an actual reference
to the EntityInstanceA object.
Remember, Core Data is an *object graph* mechanism with a persistent
store (which happens to look a lot like a database). So, it's easiest
to use Core Data if you model your object relationships as Core Data
relationships.
Is that any help?
_______________________________________________
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