Re: NEWBIE: Core Data Orientation questions
Re: NEWBIE: Core Data Orientation questions
- Subject: Re: NEWBIE: Core Data Orientation questions
- From: Chris Hanson <email@hidden>
- Date: Wed, 22 Jun 2005 22:44:57 -0700
On Jun 22, 2005, at 10:01 PM, J Tichenor wrote:
I have a bunch of entities, each with some number of properties. I
can use the data modeller to build the basic structure of each
entity, but if I want entities that have more out of the ordinary
behavior -- calculated sums, notification of events, etc -- then I
need to subclass the NSManagedObject to include this unique behavior.
This is correct.
I would then change the class in the Entity modeler to reflect this
subclass. From that point forward, I could add new properties
either in code or in the modeler, depending on how unique my
subclass of NSManagedObject is to that particular entity?
This is correct. You would add new properties in your data model if
you want them to be managed by Core Data, you would add them in code
if you don't want Core Data to care about them.
How often or unusual would it be for an application to have more
than one Managed Object Context?
That depends on your application's needs. The combination of one or
more persistent stores, a persistent store coordinator, and one or
more managed object contexts is commonly referred to as a "stack."
If you have a document-based application where each document is
represented primarily by a single window, you'd probably want one
stack per document, with one persistent store and one managed object
context.
On the other hand, if you have an application that uses a single
persistent store but displays multiple windows, you might use
multiple managed object contexts on top of a single persistent store
coordinator and store, one per window. This will
At what point would you feel that a Managed Object Context would
become unwieldy -- 100 entities? 1000?
It's important to distinguish between entities themselves and the
*instances* of entities that make up your object graph. That said,
there's no hard and fast rule for how many instances in one object
graph will make your application unwieldy; that depends on what kind
of performance requirements you have, and your object model's design
itself.
And if one were to create more than one Context, what would be the
mechanism for communication between each Context?
I'm not sure what you mean. Are you referring to change
propagation? Changes to the object graph are not automatically
propagated from one context to another; you have to manage that
yourself in the way that's most appropriate to your application.
Can data storage happen in the same persistent file with multiple
Contexts?
Yes, with the caveat that you need to understand the characteristics
of the persistent store type you're using. SQLite stores support
partial updates. XML and binary stores perform atomic saves, which
means that the entire store file is re-written.
If I want to programmatically dig into a Context, I assume that I
would find the Entity that interests me and then pull out the
property description relevant to query, either through fetching or
through classic ObjC programming?
You can easily construct a fetch request to find all the instances of
a particular entity you need to work with, and execute it. You can
also follow relationships between instances without having to pull
the destination into a context yourself.
One thing that's important to note is that managed objects don't live
in managed object contexts. Contexts are a temporary thing;
persistent stores are where managed objects actually live. So when
you ask a context to execute a fetch request, it's actually fetching
objects across all of the persistent stores its persistent store
coordinator knows about, merged with all of the inserted and changed
objects in the context.
-- Chris
_______________________________________________
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