This post is a follow-up to another post I wrote on the very same subject. I am showing here the full implementation of a NSPersistentDocument based class that allows to use package documents embedding a Core Data store. I short, what this post adds to the previous one is: improved encapsulation; NSDocumentController subclass to correctly. My Core Data document-based application crashes on 'save as'. The problem seems similar to the one described in the cocoa-dev thread titled 'NSPersistentDocument objects 'gutted' after. Jul 09, 2007 So I did not even bother to try it. If you don’t use file wrappers, you will quickly hit a wall, because NSPersistentDocument swaps documents around, and if you don’t use file wrapper it will do that with the Core Data data file instead of with the whole package. An approach that leads nowhere. An approach I tried out is the following.
- Core Data Tutorial Iphone
- Nspersistentdocument Core Data Tutorial For Macbook Pro
- Core Data Macos
- Nspersistentdocument Core Data Tutorial For Mac Desktop
I'm building a document-based app that allows users to enter a hierarchy of geographical data. Something analogous to a tree hierarchy of areas and cities. An area has a boundary and can contain sub-areas. An area can contain cities which are just points.
An average document may contain 20 to 30 areas and 500 to 2000 cities. The largest document would contain about 100 areas and 25000 cities.
I'm new to Cocoa programming and I don't know if a data set in that size range qualifies as 'small', 'medium', 'large' or 'very large'. Knowing that would help me determine how to to store and load the data.
Two quotations I've read on the topic:
'If you have a large data set or require a managed object model, you may want to use
Core Data Tutorial Iphone
to create a document-based app that uses the Core Data framework.' - Document-Based App Programming Guide for Mac'Applications using very large data sets would likely benefit from a custom persistance implementation. Core Data's reliance on KVC carries with it a significant overhead. We expect pure Swift objects would offer the best performance in terms of low overhead property access' - Cocoa Programming for OS X 5th edition
For my data set size, would I be best served looking at archiving with the NSCoding protocol, core data, or something custom?
Home > Articles > Home & Office Computing > Mac OS X
␡
- Adjusting Your Code
Nspersistentdocument Core Data Tutorial For Macbook Pro
Like this article? We recommend
Like this article? We recommend
Adjusting Your Code
By default, data migration is not turned on for any application. Fortunately it is very easy to turn on automatic code migration, but the manner in which you turn it on is dependent on the type of application you are designing. When it comes to Core Data, there are two application models that differ drastically in their handling of the Core Data Stack: the document model and the non-document model.
Document Model
In a document model, each document has its own Core Data stack that is constructed when the NSPersistentDocument is initialized. In this case, to enable Core Data automatic migration you simply need to override one method call in your subclass of the NSPersistentDocument:
Core Data Macos
When Core Data attempts to load a persistent store, this method is called. To turn on automatic migration, all that is needed is to add the option in the store options as follows:
Once you have set the NSMigratePersistentStoresAutomaticallyOption flag, Core Data will attempt to automatically migrate any persistent store that does not match the store that is flagged as current.
Non-Document Model
Things are a bit different in a non–document-based application. Generally, the loading and handling of the Core Data stack is performed in the application delegate instead of in a document object. Therefore configuring Core Data to do automatic migration is also a bit different.
Nspersistentdocument Core Data Tutorial For Mac Desktop
Normally, a non–document-based application will have a method to load up the persistent store that looks something like the following:
The only change that is required to turn on automatic store migration is to add the option, similar to the document model above, to the -(id)addPersistentStoreWithType: configuration: URL: options: error: method. You can see the change in the updated method below:
With that one change, Core Data will detect and migrate your persistent stores automatically.
Related Resources
- Book $55.99
- eBook (Watermarked) $55.99
- Web Edition $55.99