Re: Populating a new SQLite Core Data store with default data
Re: Populating a new SQLite Core Data store with default data
- Subject: Re: Populating a new SQLite Core Data store with default data
- From: Quincey Morris <email@hidden>
- Date: Mon, 23 Feb 2009 11:55:27 -0800
On Feb 23, 2009, at 11:09, Jon C. Munson II wrote:
[Jon C. Munson II] Here's what I tried:
NSManagedObject *someObject = [NSEntityDescription insert...];
someObject.attribute = @"";
and also:
NSManagedObject *someObject = [NSEntityDescription insert...];
[someObject setAttribute:@""];
Neither would work.
Clearly, these won't compile because NSManagedObject (the class) is
not declared to have a property called "attribute". As it happens,
someObject (the instance) *does* have such an attribute (assuming a
suitable entity description in your core data model), so the trick is
to figure out how to get to it. The documentation mmalc linked to
*does* tell you how, but you have to follow along fairly carefully.
There are actually three main approaches to solving this *compile-
time* issue:
#1. You don't add any auxiliary declarations. In this case, you must
use [valueForKey:] and [setValue:forKey:]. There's absolutely nothing
wrong with this, except that it is "considerably" slower than the
other 2 approaches. Keep in mind, though, that what's slower is only
the resolving of the generic KVC method to the internal core data
method. (Call that the "accessor overhead".) The actual retrieval or
modification of the property is the same no matter how you get there.
Unless you are trying to create and set attributes for a large number
(thousands) of objects in a short period of time, the accessor
overhead is unlikely to be a problem you should agonize over.
#2. You use a custom subclass of NSManagedObject (which you specify in
entity description of the core data model), and in that subclass's .h
file you put @property declarations for the properties, and in that
subclass's .m file you define the properties with @dynamic. Then the
object you get back from [NSEntityDescription insert...] is actually
an instance of your subclass, so you can simply cast it to the correct
type and use the more-efficient accessors (similar to the code above).
#3. You use a custom subclass of NSManagedObject, and in addition you
write custom accessors for various properties. There are different
ways to do this (all in the documentation too), but this is not
relevant to what you're trying to do here.
Unfortunately, the documentation doesn't separate case #2 from case #3
very well. It's easy to skip over stuff that appears to be about #3
when it contains information relevant to #2.
So although the *recommended* approach may be #2, I don't see any real
problem in your continuing to use #1 -- provided the number of objects
is not large. Also, if you find yourself using the generic KVO setter/
getter for the same key in lots of places, it's probably worth
switching to approach #2 at least for the sake of code readability.
[Note: in approach #2, to get to core data's built-in to-many
accessors (addXxxObject:, removeXxxObject: etc), you have to use a
slight hack involving declarations within a category of your subclass,
since there's no equivalent to @dynamic for that those accessors.
That's also in the documentation.]
_______________________________________________
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