- Update your Development Environment.
- break 90% of your samples to that they either don’t compile because your users are using a version of the environment that is too new, or a version that is too old with a couple of things in the middle. (I’m on Snow Leopard and Xcode 4… which is a reasonable combination and I expect it to be supported).
- sneak in undocumented autosave so that every mistake gets nailed down without options to undo. (I can’t be the only person ever who’ll try something, find it doesn’t work and try to revert to the previous, working, version… which no longer exists.)
- break basic features in a way that is undocumented, frustrating, counterintuitive, and that takes hours to resolve.
What was my crime?
I created an application with a Core Data model. I compiled the application, found it didn’t work, made some changes, including to the Core Data model, recompiled it, and got The managed object model version used to open the persistent store is incompatible with the one that was used to create the persistent store.
I have created dozens of Core Data applications. I have changed the models in them hundreds of times… in Xcode 2.5. And every time, when I’ve used ‘build-and-run’ I was presented with a new persistent store that WORKED.
This is the behaviour I expect. I’m developing an application. Once you build the finished thing, writing a permanent store and forcing developers to maintain version control and backwards compatibility is a good thing. During the build-and-run phase, it’s a very stupid behaviour. I am not creating precious, valuable data… *I am developing an application*.
So, I’m not the first person to run into this problem.
The helpful answer (well, it helped the original poster), says: If you use a single store for the whole application (not document based), then you should look in the code that creates the store object to find the location. The template places the creation code in the application delegate, and the default location for the store is in ${HOME}/Library/Application Support/${APP_NAME}/
So I looked there.
Nothing.
According to my app delegate, there ought to be a file named Outline_Test.storedata. Not on my hard drive.
To cut a very long story short, there isn’t a file associated with this app anywhere visibile. Even deleting the app and the project does not delete the invisible, hidden data store: creating a completely new project with the same name leads to the same compatibility error. (And gives me NO chance of restoring the old version and migrating the version: once you’ve used a name it seems as if you will never EVER be able to use it again. This is an order of bad design that makes my blood boil just thinking about it.)
The documentation here talks about the different types of data stores and their advantages… without mentioning where you might set them.
You’re just automagically supposed to intuit. And yes, I *have* tried to read TFM as much as I was able to download it, and I *have* looked at each and every promising possible setting I could find, but I was not able to identify where to tell Xcode which kind of data store to use.
Marcus S. Zarra in his comprehensive book on Core Data…
… is just as silent. There’s not even an entry for sqllite in the index, and while he, too, tells you which storage formats you might choose, he omits telling you HOW TO FUCKING CHOOSE THEM.
I admit defeat on this one. I cannot, no matter how far I look and root around on my hard drive and search for anything associated with my damn application find the place where the data has been written. This is very very bad news, because I use Core Data a lot and I have created and run and experimented with *a lot* of Core Data apps, all of which appear to have written invisible, undeletable data SOMEWHERE on my hard drive, files which I cannot find, cannot delete, and which seems destined to hang around forever.
So this is a FAIL on several levels:
- there’s no visible or documented way of declaring the store type when you start creating your application
- your application’s data is not (despite assurances to the contrary) stored in an accessible space
- there is no way of clearing out that store and doing a clean rebuild during development (‘This is not compatible: overwrite data store’ would do just fine, thank you)
- the application’s data store hangs around even when the application is deleted; it persists when you create a new project with the same name that allegedly stores its files in a different location
- the documentation sucks. It completely absolutely utterly sucks.
I don’t know where to go from here. The sensible way forward would be to NOT run any new Core Data projects until I know where the fucking data is stored because this is creating invisible, unfindable files on my hard drive. I feel that I have gotten as far as I can – I’ve looked at the damn thing, I’ve read the documentation, I’ve searched my hard drive, I’ve rooted around in books, I’ve opened all packages (which doesn’t explain why creating a NEW project with the same name leads to the same error as before) – the long and short is that I CANNOT find the data, I CANNOT work this out, and I am completely baffled where to go for help since the hivemind of the Internet hasn’t given me any workable solution, either.
I expected to encounter this type of problem sooner or later, but if the app I’m trying to program is the equivalent of a novel, I didn’t expect to stumble over ‘It was’.
This is supposed to be a hobby. It’s supposed to be fun. And those people for whom programming form part of their livelyhood don’t deserve having to spend hours batting their heads against walls over very simple things, either.
I am deeply disappointed at Apple and am rapidly losing trust in their Cocoa development team, because this is a failure on several levels – design, preferences, documentation.
And I’m not imagining things. CocoaDevCentral says quite clearly The data store is defined in the -managedObjectContext method, which is generated automatically when you create the project. My managedObjectContext method contains no such line as
url = [NSURL fileURLWithPath: [applicationSupportFolder stringByAppendingPathComponent: @"BlogDemo.xml"]]; ... if ([coordinator addPersistentStoreWithType: NSXMLStoreType configuration: nil URL: url options: nil error: &error]) ...
Part of that code is spread around other functions, but this means that the help I can get is not valid for the auto-generated code I am working with – as far as I can read my code it a) ought to create an XML store (addPersistentStoreWithType:NSXMLStoreType) in a ‘Outline_Test’ directory ([libraryURL URLByAppendingPathComponent:@"Outline_Test"]).
There is no such folder. There’s a Outline_Test-aebwvrtqgkvjspduholxgeckmgki folder – I am *so* impressed that Xcode4 is creating monster folders like this for every project I run – and that there’s nothing in the code that would indicate to me that this is going to be created. There’s also no .xml file that I can find anywhere.
I really truly *do* give up. And hope that someone, somewhere on this planet with more patience and more magical ability will work this out and put the solution somewhere I can find it. In the meantime, unless I want to give up programming for good, I have to resign myself to creating zombie files on my hard drive, and that makes me absolutely utterly FURIOUS.