Architecture
For maximum safety and performance, CoreStore will enforce coding patterns and practices it was designed for. (Don't worry, it's not as scary as it sounds.) But it is advisable to understand the "magic" of CoreStore before you use it in your apps.
If you are already familiar with the inner workings of CoreData, here is a mapping of CoreStore abstractions:
| Core Data | CoreStore |
|---|---|
NSManagedObjectModel / NSPersistentStoreCoordinator(.xcdatamodeld file) |
DataStack |
NSPersistentStore("Configuration"s in the .xcdatamodeld file) |
DataStack configuration(multiple sqlite / in-memory stores per stack) |
NSManagedObjectContext |
BaseDataTransaction subclasses( SynchronousDataTransaction, AsynchronousDataTransaction, DetachedDataTransaction) |
Popular libraries RestKit and MagicalRecord set up their NSManagedObjectContexts this way:
Nesting context saves from child context to the root context ensures maximum data integrity between contexts without blocking the main queue. But as Florian Kugler's investigation found out, merging contexts is still by far faster than saving nested contexts. CoreStore's DataStack takes the best of both worlds by treating the main NSManagedObjectContext as a read-only context, and only allows changes to be made within transactions on the child context:
This allows for a butter-smooth main thread, while still taking advantage of safe nested contexts.