Re: Core data accessors for structs
Re: Core data accessors for structs
- Subject: Re: Core data accessors for structs
- From: Kaelin Colclasure <email@hidden>
- Date: Tue, 26 Jun 2007 10:34:37 -0700
On Jun 26, 2007, at 9:48 AM, Jim Correia wrote:
On Jun 26, 2007, at 2:21 AM, MH wrote:
What is the best way to encode a struct so as to obtain
persistence using
the Core Data framework, and avoid the pitfalls mentioned?
Should I be following the non-object guidelines supplied by Apple,
and use
shadow attributes? This doesn't seem to address the problem
mentioned by
Jim
Whether or not you use a shadow attribute, or on-demand encode/
decode is going to depend on your specific needs. There are several
patterns discussed in the documentation.
What are your reasons for using a structure? If it is for raw
performance, you probably don't want to on-demand encode/decode the
value every time the accessors are used. If you don't have a
compelling reason for using a structure, you may want to consider
changing the model.
As for the encoding issue, you have several options for encoding
your structure in a way that will allow you to easily use the
result on a platform with different endianness, integer sizes,
structure padding, etc.. One solution is to use NSKeyedArchiver and
individually encode/decode the fields of the structure.
If the structs are there for performance, you might consider tagging
them with a byte-order flag and coding a swap routine that will fix
up the byte order if necessary when your object is faulted into
memory. This is ideal when most of the time your data will be used on
the same system -- it's stored in native byte order, and no extra
work is needed at fault time.
-- Kaelin
_______________________________________________
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