Re: CoreData : fundamental (or not) questions
Re: CoreData : fundamental (or not) questions
- Subject: Re: CoreData : fundamental (or not) questions
- From: Joshua Scott Emmons <email@hidden>
- Date: Sun, 19 Mar 2006 10:23:15 -0600
These are not cannonical answers -- just based on my usage of it.
1- In which cases is it necessary to create another
managedObjectContext, instead of using the default moc of the
NSPersistentDocument ? Of course if you have different persistent
stores it seems to be necessary, but in the simple case : 1
managedObjectModel, 1 persistentStore ?
I've never found a reason to if you only have one persistentStore.
And keep in mind that the Document-based Application model uses
NSDocument's managedObjectContext to abstract most of this away from
the programmer anyway. By which I mean: in a multi-document
application, you will have a persistent store for EACH document. This
means you will have a separate managed object context for each
document. But as long as you are always using the managed object
context of the document you are interested in (by calling [NSDocument
managedObjectContext], you never really have to think about it.
2- How can I access the default moc of the document from an entity
(I mean by entity, a class created from an entity) ?
I'm a little unsure what you mean by "class created from an entity",
but I think you mean an NSManagedObject or subclass thereof. If
that's the case, you can call [NSManagedObject managedObjectContext]
to get the MOC of that entity (and anything else in that entity's
store). The only time that wouldn't work is if you have multiple
stores and are trying to get the MOC of a store that your entity
isn't a part of.
3- How can I access the methods of an arrayController from an entity?
Generally, I don't think this is a good design decision. It will
likely make things more confusing down the road. In the whole MVC
scheme of things, your managed objects, entities, relationships, and
all that CoreData jazz are your Model. Your NSArrayController is
(obviously) your controller.
Ideally you'd want your Controller to tell your Model things like
"Create a new thing" or "Delete this thing". You want your Model to
say things like "I have created this" and "I will delete this".
Calling methods of your Controller from your Model insinuates that
you are going to have your Model make the Controller say "Create
this" or "Delete this" which is kind of self-referential and messy.
If what you are looking for is a way to let your Model tell your
controller "I've created this" or "I've deleted this" (so that the
controller could update the view or something), it's already done for
you in Core Data! Just set your controller up to do some KVO of your
managed objects:
[myController addObserver:myManagedObject
forKeyPath:@"myPropertyOrRelationship" options:0 context:NULL];
Whenever myPropertyOrRelationship changed, myController is sent a
-observeValueForKeyPath:ofObject:change:context:
message. Note that depending on the values of options: and whether
this is a property or a relationship you are observing, ofObject: and
change: can pass in some really interesting values.
Doing things up this way prevents you from adding any application-
specific code to your model. Everything is in your controller
instead, keeping things nice and neat. If you don't know how to use a
method like this to solve your problem, maybe you could describe it
and see if someone here can find a way to make it fit? I really think
calling your controller from your model would be a bad idea.
Cheers,
-Joshua Emmons
_______________________________________________
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