Re: NEWBIE: Core Data Orientation questions
Re: NEWBIE: Core Data Orientation questions
- Subject: Re: NEWBIE: Core Data Orientation questions
- From: J Tichenor <email@hidden>
- Date: Thu, 23 Jun 2005 09:43:24 -0700
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.
Although I could add them programmatically outside of the data
modeler and still have Core Data track them. Or just have good old
classic iVars outside of the core data framework...
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
Trying to see this model in my head. I have an database like
application with multiple windows and views inside tabbed windows.
Not sure how to delineate between multiple contexts, although I
suppose depending on the task the context could change.
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.
Yes, talking entities and not instances. I'm sort of paralleling
entities in my modeler with classes that I have written pre-CD. At
the moment, have about 20 classes, but could see that number double
or more.
One thing I'm not so keen on is the abstract nature of Entities and
their properties. Particularly using KVC. I feel a little weird about
leaving the wonderful world of objects for something that is a
little more ... dunno, abstract... to create models in one's mind.
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.
Yes that's what I meant. Keeping two contexts in sync.
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.
Ok, that is a good thing to remember. In other words, I could have
five different stores registered with a context and the context will
deal with all the objects in all the stores when doing fetches.
Depending on the storage method I'm either calling the whole store
into short term memory for manipulation or I'm grabbing what's needed
as it's needed. My guess is future and full database support is
something to watch for in v2+...
-- Chris
J
_______________________________________________
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