I created one project with core data that will work with unchangeable database. And I don't want to write code in this project , that will programmatically populate this database. So, I create second project with core data, add existing xcdatamodel from first project without copying(only references). There i populate my database, open it with mozilla plug-in and it successfully filled. Then I copy ,my *.sqlite file and manually replace it with old file in first project. It causes error:"The model used to open the store is incompatible with the one used to create the store". But I use for both files the same xcdatamodelid. Where my error?
Sorry for my english, I really need help.
P.S. when I open sqlite file from first project and second (with commented code of populate base) in FileMerge - second is already empty. I appreciate any advice or help.
Karoly S nicely answers the question. I have a hint that I frequently employ that may prevent this out of sync situation. Instead of two Xcode projects trying to share one model file, just create one Xcode project with two targets. Each target will use the same model file, any class definitions derived from that model, and possibly other code. My second target is a Mac OS command line program that generates the database, while my first target continues to be the iOS app that reads that database. The Mac OS target will overwrite the database file in a project subdirectory, ensuring it's up-to-date. If I make any changes to the model, Xcode knows to update both targets.
Did you change your Model Definitions in any way? The error you are seeing is because there is some difference between the model from when you created it, and again from when you are trying to reference it. Are you running on the simulator? Try to delete both of your apps to clear the data related to it, as it might be out of date. Afterwards simply rebuild both of your projects as that will update your core data database.
EDIT: To clarify a bit more, your core data model is out of sync, this is generally caused by you building and running an app, and a database being created, then redefining your object model, this can be done in a variety of ways, most likely caused by the addition of an attribute or entity. So when you are trying to load the database there are fields that the app and core data are looking for, but are not there because they did not exist when the database was created. I hope this helps.
Related
I want to bundle read-only realm database with my app. I was able to do this by following this tutorial. There are couple of issues with this solution though. The fact that I had to create another xcode project for it comes with various cons like:
I have to keep duplicates of my classes inheriting from Realm Object and manually keep them in sync between two projects
I have to open another project each time I want to create new updated realm database
It would be weird to keep 2 xcode projects in one git repository
My question is: Is it possible to add some kind of standalone script to my project that would have access to my realm objects and realm library that I could manually run from time to time instead of having to do that in another project?
I was looking into adding playground and running it from there, but I think that swift package manager is currently bugged in a way that doesn't allow to build such a solution as I'm getting This will result in duplication of library code. error that cannot be fixed with DISABLE_DIAMOND_PROBLEM_DIAGNOSTIC flag.
Is there some other solution than having to do it within another project? I think there must be a way to run utility scripts like this - that aren't strictly part of the app, but surprisingly I couldn't find any so far.
I started new project without core data checked and then I tried to put it in manually. So everything is fine but I have a question concerning Codegen in Data Model Inspector.
When I put class definition in Codegen field my class was redefined in appropriate to core data way so I deleted my old one. And after I saw extension of this new class where I could find all the properties.
So after I closed I couldn't find it in my project but I want to see it again.
How can I make it appear again?
When an NSManagedObjectModel is configured to generate code, it doesn't add that code to your project. Rather, it generates that code into your Derived Data, in the DerivedSources directory for the target the model is a part of.
In Objective-C, you can just use #import "ModelName+ManagedObjectModel.h" in your other code to gain access any of the entities for which code has been generated. In Swift, you don't even need to do that, you can just use the classes that were generated.
If you want to see the code for those classes, you can use Open Quickly (command-shift-O) and type in one of the class names. Xcode should take you right to the generated source code for it.
I'm working to get rid of a bunch of warnings in our codebase of the form:
Entity.relationship should have an inverse.
In general, although our code does not reach through these inverses, it sounds like it is a good idea to put them in anyway.
My question is about how I would do this.
Should I make these changes through a lightweight migration? That is, should I be creating another xcdatamodel?
For the given data model, what if we already have multiple versions/migrations. For example supposed we have the ReportsDataModel. And underneath that are ReportsDataModel1, ReportsDataModel2, and ReportsDataModel3. It seems like XCode 7 is giving me the same warnings on each data model. So if I fixed them in a lightweight migration to ReportsDataModel4, it seems like it wouldn't get rid of the previous warnings.
What is the recommended way to get around this issue?
-Arjun
First of all, you would be correct that you should implement the inverse relationships, as Xcode requires them. It's a good database practice, and you can virtually ignore the excess relationships if you're not using them.
Yes, you should be able to perform a lightweight migration, that is, create a new data model and let Xcode infer the changes. Here, Apple states that lightweight migration supports adding relationships.
Regarding your second question, true, creating another data model will not actually solve the warning in the older ones. You must leave the older models in Xcode so it can compute the lightweight migration process. If you erase a model and a user updates from an older version that uses that model, their data will be corrupted. (However, if you haven't published a version of the app with a particular data model, you can delete that data model.)
However, you can try suppressing the inverse relationship warning entirely.
In Xcode, click on your project file.
Click the Build Settings tab.
Search for MOMC.
Set Suppress momc warnings on missing inverse relationships to Yes.
EDIT about getting rid of the warnings on only the old models: This question suggests that you could move the old data model out of Xcode and place it elsewhere, and add a Copy Files action to Build Phases to copy the file back in at compile time. This way the file and it's extraneous warnings could be out of your way. Sorry there isn't a less "hacky" solution.
I will start developing a new project for iOS. I am unsure for now if I should use core data in this project, or not. I will find out along the way, while developing (most likely with some coaching help).
Now my noob question is: Should I, while creating my new project, already check the option 'use core data'? Or shouldnt I?
Basically my question is: What is more difficult, removing core data when I checked the option and I will not been using it after all? Or adding core data when I did not check the option and I will be using it after all?
I have found it is not super difficult to add after:Implement CoreData into an existing project using Swift
But still, it seems like alot of hassle, so I now ask u!
Thanks for the answer in advance
It doesn't matter. Starting with Core Data just prepares the core data code in the app delegate and makes an empty model file, both of which are
1) easy to create yourself, or
2) copy from a new empty project started with core data later when you need it.
And if you already have it in your project, but you don't use it, it is also no problem. I found that almost all projects need core data after a while, so I usually just let it create it from the start.
Xcode just allows you to check using coredata to prepare already a coredata for you project.
BUt it is very simple to add or remove it later.JUst simple as File>create or File delete.
In a words don't worry about creating in the begining or later.
I'm using CoreData for one of my databases, and I'm having trouble with an upgrade to my App.
My old databases are no longer loading ... I get the error "Cocoa error 134190" which I believe means that the inferred mapping model is failing.
When I started editing this version of my App, I created a new model version, and I simply added one new attribute to one entity, and two new attributes to another entity. Nothing was changed or deleted.
I've checked inside my App's directory, and all of the model versions are there.
I even have a snapshot of my previous version of the App, and with that snapshot I can load my core data files.
To debug what is going wrong, I took the exact data model from my previous snapshot and used it in my current version, and I still get the error.
I've even done a "diff" on every file in my ".app" directory packages, and there are only two files that are different between the two. One is the actual binary for the application, and the other is the "Info.plist" file. I looked at the Info.plist files, and they too are basically identical (the new one has a newer bundle version, but no other change).
Any idea why the inferred mapping is broken?
I am getting the same error even when the data models are completely unchanged from my last version which works.
This is extremely frustrating.
Any information as to how to track down problems like this in the future would also be greatly appreciated!!!
I found the answer ... the problem was that in my new version, I was rearranging the locations of my files. I did so by simply moving the database to a new location. What I didn't realize is that coredata databases have some knowledge of their path built in, and you can't simply move them.
I needed to change the location of the database using the NSPersistentStoreCoordinator's method:
migratePersistentStore:toURL:options:withType:error:
My fault, but I really wish that core data error messages weren't so cryptic.
In the next version of my App, I'm going to remove core data completely.
Ron
I don't believe core data actually cares where the database file is, but I could be wrong. In the times I have seen this error, specifically "Cocoa error 134190" while trying to infer a model mapping, it's been the case that there was actually a problem trying to migrate to the next version of the model.
For example, when I found this thread today because I was helping someone with this problem, the real underlying issue was that the type of one of the attributes was accidentally changed. The automatic migration can't handle that sort of change.
A somewhat easy way to look at the changes between two model versions is to diff the description files themselves on the command line with diff:
diff yourNameHere.xcdatamodeld/yourNameHere5.xcdatamodel/contents yourNameHere.xcdatamodeld/yourNameHere4.xcdatamodel/contents
(That assumes you have a core data model description named "yourNameHere" and you're looking at a problem migrating from version 4 to 5. You'll have to adjust for your specific files.) In this diff you should see whatever additional things you've added, but you're really looking for something like a type changing when it shouldn't.