Question for Simperium:
A badly-written XC unit test wiped most data from a simperium user account (mine.) No problem. I moved a day-old back-up of the sqlite file into an iPhone 5 (iOS 9.1) simulator, and deleted the now-useless sqlite file from the same Documents directory.
I performed a clean (SHIFT-COMMAND-K), and started the simulator. All my missing data now appeared in the app simulator. Great.
BUT restored Core Data records did not then get synced to corresponding Simperium buckets. Puzzling as Simperium DID respond successfully to syncing new records on create, update, and delete actions.
I then deleted the entire data set on Simperium.com. Same result. New records syncing no problem, old records no.
Is there important meta-data that I deleted when deleting the old sqlite file. If so, (how) can I get old records to re-sync?
What's going on is: the method that should pick up those 'new old entities' is getting bypassed, because all of them already have both, a Key + GhostData.
This scenario should normally recover automatically, granted that those entities get updated somehow (that way the lib would pick them up and sync them with the backend).
The easiest way to force a re-upload would be:
In your app, add a (temporary + helper method) that gets executed right after Simperium is initialized (and thus, the Core Data stack is wired), but before the authenticate method is called.
Loop through all of the entities in that bucket and set to nil both, the simperiumKey and ghostData value.
Run your app just once
Kill this helper method (otherwise it'd probably cause duplicate entries!).
(Untested), but that should do the trick!
Related
My app under development uses core data.
When I add an optional attribute to an entity, I expected that automatic lightweight migration is done, because I use an NSPersistentCloudKitContainer, and all my NSPersistentStoreDescription have the default settings shouldMigrateStoreAutomatically = true and shouldInferMappingModelAutomatically = true.
After changing the xcdatamodeld file by adding an attribute and restarting the app with the old persistent store, no data is fetched, and no error is reported.
However when I re-install the app, everything works fine, because a new persistent store is filled with the iCloud data.
Maybe I can detect that the model has changed, delete the old persistent store, and setup a new one that is synced then with iCloud.
But it should also work without iCloud sync: I thought the old persistent store should be automatically migrated to the new model, i.e., the newly added attribute should be initialized with nil.
Is this a misunderstanding? Do I miss something? How to do the migration correctly?
PS: I have read this answer, but since my app is still under development, I thought I don't need different versions of the model, but could simply update it.
I'm working for an iOS app that was earlier developed using phone gap. It is having a sqlite database for storing data. But now while developing the same app in native, I'm using core data for storing the data.
Now when the new native app replaces the old phone gap app on user's device, I want to copy data from already existing sqlite file into core data.
So when I run the application on device with phone gap build pre installed my app(native) replaces the old build as I'm using same bundle ID but I'm not able to find out the path to that sqlite file. Does sqlite file still exists in documents directory?
If you have an example old database file still installed on one of your devices you could try downloading the App off the device using the Device manager in Xcode.
Then you open up the bundle and search for your file. Then if you know its location / name you can simply access it, read it using some SQLite library and load the data into your CoreData backing store. Keep in mind you either want to mark it in NSUserDefaults or delete the old DB all together so your app does not keep on migrating ( And then maybe accidentally deleting new data from a user. ) I would choose for keeping the old one around for at least a version or 2 so you can verify that your migration works without bugs / deleting user data in the process.
Tip: It is probably a good idea depending on how big your database is to show the user some kind of progress or "migrating / optimizing db" while you're doing this. So you don't end up with the user adding more data to the database before you're done migrating.
My app is using Core Data framework with storage type of sqlite . I received several feedback commenting that user data stored in Core Data is lost, it seems the sqlite file read fail. After i got the sqlite files from user, there are 3 files (.sqlite, .sqlite-wal, .sqlite-shm).
But only empty results can be queried in these sqlite files.
What I got from the users is they may power off their iPhone while the app is active.
I just noticed Core Data begin use WAL as the default journal_mode in ios7, while it's default as DELETE prior to ios7. I didn't set up the journal_mode manually in my code.
I'm not sure what is the root cause of this issue. But data lost is unacceptable to users anyway. Did anyone happen to meet this issue before?
Should I set up the journal_mode to DELETE manually for all iOS version?
Thank you!
Update：
User reported it works normally on previous day, but then everything is lost on next day.
i have submitted an app on the app store that uses core data.
The problem is that i duplicated my project and then lost the first source code. If i update the app using the "duplicated" source code does it delete all core datas users may have stored? i know that if you change the file file-xcdatamodel without mapping the previous datas you will lose all you had stored, can i assume the duplicated project use the exact same file?
thanks in advance
In that case I think that, if you didn't modify your xcdatamodel, the data stored by user will keep during the upgrade. In order to be sure, you can install your own apo from App Store, save some data, update this app from Xcode with your new version and check if the stored data still are there.
If you've modify your xcdatamodel, you must perform a light or a heavy migration, depending on your canges.
I am updating an old iOS app which used sqlite database. I changed the database structure adding columns to existing tables. Now, I am testing it on my device. If I clear my old app from iPad and then run this new updated version on it, it is working fine. But if I have the old version installed on ipad already and test this updated version, it is somehow using the old database instead of the one updated. Can some one help me why it is doing this?
My guess and to try and make a simple answer for you is this. It's likely you updated the database in the project file - which means when you run it, your new db will exist in the bundle. files in the bundle cannot be updated, so its common practice to copy the database out of the bundle and store it somewhere in the ios sandbox. I usually use the documents directory to keep it simple.
Most likely what is happening is that when you run it over a pervious install, it see's that the file is already copied over to the device so it does not touch it, however on new installs, it probably sees the database is missing so it copies it there and that is why on new installs it works fine but existing ones it does not.
Look in the app delegate or your root view controller for code that checks for the existing database and copies the database over if needed on startup.
If you need to update the database on existing installs, you would need to force the copy.
Beware though if you have data in the existing database not to overwrite it if its important. If important data is stored there, you have to either do a little shell game of getting the data and importing into the new database, or maybe a simpler way, is to run the database schema modification commands on the existing database so it is the same.
again, beware and make a copy of the local database file before you run those commands, just in case.
best of luck
In iOS, a SQLLite database is really just a file. When you used the old app, it created the schema in the database file. When you load the new app, the data remains, untouched. If you want to use the new schema, you will have to detect the old schema and update the existing data. I believe that there are documented ways to deal with this. Bryanmac's question reference seems to be a good place to start.
When you install a new version of your app, iOS actually installs it in a new directory and then copies the contents of the documents folder from the older version to the one in the newer version. If you want to just use your new db, the best way is to have this db renamed or stored in a different directory inside your app's document store.
Here's a relevant article on updating An sqlite CoreData backing store on iOS:
http://www.musicalgeometry.com/?p=1736