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 protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
