macOS strategy for data entry - core data and managed object contexts

[sgthree]

I am developing an application to manage entrants in a marathon as a means to teach myself objective-C and cocoa.

The application uses core data for data storage.

I want to have a single window that handles the competitor detail data entry and edit. I originally modeled the design on the Departments and Employees example from the Apple Developer website, where a sheet opens with its own managed object context, and when the user finishes data entry, the details are copied from the sheet managed object context to the document managed object context. I have a running application that can edit data, but not add it (this may sound back to front, but I have already implemented the importation of competitor data from the online registration system)

My problem is that whereas the Department and Employees example was dealing with a single managed object in the sheet, my application has to deal with a number of managed objects and relationships (what events they have entered, what merchandise they have bought, what payments etc they have made). Whereas the Apple example simply copies information for one managed object from one context to another (which is a achieved in 4 lines of simple code), I have to recreate all the managed objects and then recreate all the relationships as well.

I am now wondering why not do this all on the main managed object context.

Is there a right/wrong way of doing this - am I better sticking to the separate contexts, or is it simpler to do it all on the main context?

 

[GorillaPaws]

Is there a right/wrong way of doing this - am I better sticking to the separate contexts, or is it simpler to do it all on the main context?

I would start simply and add complexity as the problem necessitates. I know that concurrent code can require multiple MOC's but I don't see why you can't graph all of the relationships into one Managed Object Model and use a single MOC to manage them. Perhaps I'm misunderstanding your problem.

Why exactly do you believe it's necessary to have multiple managed object contexts? I.e. what limitation that you've read about in the documentation indicates you can't simply use a single MOC for your purposes?

 

[sgthree]

I would start simply and add complexity as the problem necessitates. I know that concurrent code can require multiple MOC's but I don't see why you can't graph all of the relationships into one Managed Object Model and use a single MOC to manage them. Perhaps I'm misunderstanding your problem.

Why exactly do you believe it's necessary to have multiple managed object contexts? I.e. what limitation that you've read about in the documentation indicates you can't simply use a single MOC for your purposes?

The rationale for the separate MOC is explained here: http://www.timisted.net/blog/archive/multiple-managed-object-contexts-with-core-data/

I am inclining to the view that when editing existing information in the system, I should keep it simple, and do it all on the main managed object context.

I would still however like to add new competitors by first of all entering the data via a window linked to a separate context add merchandise, payments etc, and then copy across to the main context when done.