title: Does it make sense to have multiple NSPersistentStoreCoordinators?
body: <p>I'm new to Core Data, and I'm trying to make sure that I've got my data model and its usage set up properly.</p>
  
  <p>I basically have two file types in my App ... one contains settings type data and a second contains data sets that the user will be working with (kind of like documents, although I can imagine the user working across 10s or even 100s of these files simultaneously).</p>
  
  <p>I've been reading books on Core Data, and I remember reading that typically an app has a single <code>NSPersistentStoreCoordinator</code>, a single <code>NSManagedObjectContext</code> and a single <code>NSManagedObjectModel</code>.</p>
  
  <p>I currently have a single managed object model with configurations for the various file types I have. I had been planning on also having one of the <code>NSPersistentStoreCoordinators</code> / <code>NSManagedObjectContexts</code>, and when I create new Core Data objects, I would make sure that each one was added to the correct persistent store.</p>
  
  <p>However, I've seen examples where each file has its own <code>NSPersistentStoreCoordinator</code> and <code>NSManagedObjectContext</code>.</p>
  
  <p>Are there advantages and disadvantages to having multiple <code>NSPersistentStoreCoordinators</code> and <code>NSManagedObjectContexts</code> in a single thread application?</p>
  
  <p>Initially, I had been hoping to be able to move objects from one persistent store to another during user cut and paste type edits, but that doesn't seem possible either way.</p>
  
  <p>Any advice is greatly appreciated!</p>
  
  <p><strong>Edit</strong></p>
  
  <p>Here is some more information about what is confusing me. When I read the documentation about NSPersistentStoreCoordinator, it says:</p>
  
  <blockquote>
    <p>The coordinator is designed to present
    a façade to the managed object
    contexts such that a group of
    persistent stores appears as an
    aggregate store.</p>
  </blockquote>
  
  <p>In my case, this is not what I want. I want my documents to be perceived as separate documents, and I don't want the queries to be confused between each other.</p>
  
  <p>In addition, with only one persistent store coordinator and many persistent stores, if I forget to assign an entity to the correct store on creation, I find myself with bugs since entities are arbitrarily assigned to a valid store when they are created. I'm not sure what would happen with relationships that point to objects in different stores (probably an assertion failure?).</p>
  
  <p>To me, it seems that having a single context / persistent store coordinator per store would be less prone to bugs, and allows me to keep the data for each document isolated from each other.</p>
  
  <p>The only thing that a single persistent store seems to buy me is that I can perform a save operation for all stores simultaneously which would be preferable. With multiple contexts / store coordinators, I would need to perform separate save operations.</p>
  
  <p>If you use the OSX NSPersistentDocument class, it seems to enforce a separate context / store coordinator per document.</p>
  
  <p>Anyway, from all my research, it seems that separate store coordinators / contexts would work better for my App, but the reason I posted this is because I am new to Core Data and this approach does seem to go against the recommended flow and I'm worried that I'm missing some gotchas that will come back to bite me.</p>
  
  <p><strong>More Thoughts / Information</strong></p>
  
  <p>As I think about this more and read more feedback from others (thank you everyone!!!), my current thoughts are as follows.</p>
  
  <p>For myself, there really doesn't seem to be that much difference between the two approaches and I currently believe that I could make it work well either way.</p>
  
  <p>With a single store coordinator, I need to make sure that newly created entities are attached to the correct store (not really a big deal). With multiple store coordinators, I need to make sure that newly created entities are added to the correct context (of which I will have many of them). With the way my code is structured, either approach should be relatively easy for me.</p>
  
  <p>I personally want to search a single store at a time. If I have multiple store coordinators, this is automatic. If I have a single store coordinator, I need to make sure to constrain the fetch request. (either way, not really a big deal).</p>
  
  <p>The documentation for the store coordinator implies that its advantage is making multiple stores appear as one. For my app, I do not need or want that so this is not really a consideration for me (although if I wanted to add cross-store searching capabilities in the future, it would be best to keep everything in a single store coordinator).</p>
  
  <p>To me, none of the above reasons are really good arguments either way, and if they were the only arguments, I would probably try to do things the more conventional way and stick with a single store coordinator.</p>
  
  <p>However, one final reason (and the main reason that I originally posted this question) is that I am planning on taking advantage of some features in iOS 5 that seem to require multiple store coordinators. I want to be able to weak-link my app to be backwards compatible, so it seems that having my iOS 4 code closely resemble the iOS 5 code would be preferable.</p>
  
  <p>The more I think about this, with the support for multiple OS versions, I could probably still implement things either way with the correct abstractions.</p>
  
  <p>Thank you everyone for your feedback! I'm slowly getting the hang of Core Data which has mostly been a great experience, although its given me my share of headaches as well!</p>