Re: clarifications about coredata sub to-many entities fetching
Re: clarifications about coredata sub to-many entities fetching
- Subject: Re: clarifications about coredata sub to-many entities fetching
- From: Nicolas Berloquin <email@hidden>
- Date: Sun, 10 Oct 2010 01:08:45 +0200
Thanks for your answer !
You are right, I haddn't read the docs enough. I read them quickly, then I
started using a sample code as a basis for something else, and I got mixed
up in
what belong to whom (class-wise and logic-wise).
I was probably picturing coredata as more sqlish than it is too.
I think the confusion is clearing up !
thanks again :)
On Sat, Oct 9, 2010 at 7:20 PM, Keary Suska <email@hidden>wrote:
> On Oct 9, 2010, at 3:55 AM, Nicolas Berloquin wrote:
>
> > I'm fairly new at using coreData on and I'd like to have some
> > clarifications on managedObjects and contexts usage.
>
> Honestly, it seems like you are trying to learn the API without reading the
> API docs. For instance, the "Table View Programming Guide for iPhone OS"
> addresses the kind of drill down you are describing, and NSIndexPath has
> nothing to do with it.
>
> You really should understand how UITableViews work first, and then
> separately understand how Core data works, and then try to put them
> together. Trying to understand them both at the same time, clearly, isn't
> working.
>
> It is difficult to give you meaningful answers to your questions as they
> stem from a fundamental lack of understanding of other technologies
> involved--not just core data. Regardless, I will try to touch on a few
> issues that may help point in you in some directions.
>
> > I have a model where a top entity has a couple to-many relationships,
> which
> > each have to-many relationships
> > to other entities.
> > something like this :
> >
> > A
> > to-many -> B
> > to-many -> C
> >
> > B
> > to-many -> D
> >
> > C
> > to-many -> E
> >
> > (I skipped the other attributes in the entities)
> >
> > I have a set of As, that I fetch when my app loads, and I dig into As
> > through a UITableView.
> > I show a list of As, and when the user taps an A, I show a detail view of
> > its contents.
> > The user can then access the table of Bs and Cs. And add Ds and Es...
> >
> > What I'd like to know is what I should do when I show the list of Bs for
> > example.
>
> It is probably better to traverse the relationship rather than manually
> fetching.
>
> > Should I do a new fetch (with a different fetchRequest) on the Bs, and
> have
> > this as a new context ?
>
> Why would you need a new context at all? Re-read the Core Data docs and
> understand what NSManagedObjectContext is and what it is for.
>
> > I'm not sure how do NSIndexPath work with my setup ?
>
> Probably not relevant at all. Read the table view programming guide to
> understand what NSIndexPath is for, as well how to do a hierarchical
> drill-down.
>
> > On the other hand, the same data has already been loaded when I loaded
> the As. (well, they may have only been faulted). Is it usual to "re-load"
> some parts of the tree ?
>
> Yes, the relationships will be faults until they are accessed. When
> accessed, Core data will fetch them for you--but it will only fetch what is
> necessary to fulfill the fault. Specifically, it will not fetch the entire
> data subtree. That would be terribly inefficient.
>
> > Also, when adding Ds should I pass the managed B object to my
> BviewController and do
> > [Binstance addDObject: newD]; or have B as the base of the new context
> and do [NSEntityDescription insertNewObjectForEntityForName:@"D" ...] or
> if I didn't do any new fetchRequest (staying with the As), will [Binstance
> addDObject: newD]; still do the relevant work in the hierarchy ?
>
> Core Data will maintain relational integrity. This is all clearly explained
> in the Core Data Programming Guide.
>
> > and last question (see I'm still a bit confused about the whole thing :))
> if I keep the context I got when loading the original As, and I do a
> [context save:] of new Ds, will it be as efficient as if I was to do the
> same thing with a context created with Bs as a fetchRequest ?
>
> So far, you have not made a case for needing more than one context. And you
> should avoid doing so until you know Core data better anyway. Anyway, save:
> efficiency between different contexts should only vary based on the number
> of validations and the number of changes that need to be committed.
>
> > I get the feeling that one can use a coredata hierarchy almost as
> directly as if it was a plain object hierarchy, but I'd like to make sure
> I'm not missing something along the way !
>
> Yes--you can. That is really the point of Core Data.
>
> HTH,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
>
_______________________________________________
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