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 protected]>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 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]
