Our app will ship with a pre-populated database which continually downloads updates from our production server's database to stay up to date. When we make updates to our app's codebase and push those updates out to the AppStore we'll also include an updated db.sqlite file.
My questions is: when we do this I assume it will overwrite the users "old" database file that already exists?
I assume (and hope) the answer is yes, but just wanted to double check - I couldn't find any answers in Apple's documentation, but might have simply overlooked, or have been looking for the wrong terminology.
When you say "which continually downloads updates from our production server's database" I assume that means the app will download the data and update the database? In which case the database must exist in the Documents folder and it won't get into the Documents folder until you copy it there.
Normally this is done by the app if the database file doesn't already exist, however if you want to overwrite the current database you'll need a mechanism to discover if the one in the Documents folder is out-of-date, compared to the one in the app bundle. This probably means having a "metadata" table (with two columns name/value) containing a version number or some such. You read both databases and decide whether or not to copy.
Related
I am working on a quizz app and I use realm database to store all data (questions, answers, isUserAnswered, isUserAnsweredRight, etc...).
I set up a bundle file to persist all of these data in a realm file when the user launches the app for the first time.
I would like to add new questions in by database at each update. How to persist these new questions without overriding previous data already stored in db ? It's a problem to override because I store for each question if the user has answered and if he answered right. I don't want my users to lose all their progress at each update.
This may or may not help but you could do one of a few things.
If your file contains primary keys for each object, as you are reading in the file, ignore the ones that match ones you already read in.
Another option is to version it - attach a version number to each object and only read in objects that are after the last read version.
In my IOS app, I store two types of data in CoreData. One type is user generated, the other type is a pregenerated database. Currently this is all in the same store, which goes into the documents folder. But this is not a good approach, so I will split into 2 separate stores.
There are two problems:
The pregenerated database should not be backed up by iCloud.
When an update of the app is provided, the user data should be kept, but the pregenerated database should be overwritten. (The pregenerated database will have updated content, even if the data model is unchanged.)
For problem 1, I can either put the pregenerated database store in the cache directory, or keep it in the documents directory flagged for skipping backup. As the cache directory can be emptied any time, using the documents folder without backup seems better. However, does that solve problem 2? That is, will the pregenerated database be overwritten after an update?
If not, are there any other solutions?
You can keep pregenerated rated database in document folder and flag it for skipping backup in iCloud. However you have to write some script to overwrite the data Or on update you can delete your pregenerated store completely and create it again with updated data.
My question contains two ways:
1. For example I have an app which is on appstore and containing sqlite database. After sometime I want to update app version without changing database schema. what happened when app will be updated on user's device ? would all data in old database removed or just remains with same database and data ?
2.For example I have an app which is on appstore and containing sqlite database. After sometime I want to update app version with changed database schema. what happened when app will be updated on user's device ? its must changed the DB file but how can we save old data entries those are in old DB version. I have read many posts but still confused which approach I should use.
Thanks in advance for Helping
It is quite simple. When updating the application documents folder remains intact, so you can assume that the user data continues to be available.
For case 2 make sure you do not compromise the data in your update routines at the first start after the update. The app should detect that it is in a new version and modify the schema (e.g. via SQL scripts) while taking care of not deleting user data.
My app was rejected recently due to the fact that it installs a database within a directory which will be backed up to iCloud. As the database comes with a lot of prepopulated data and the app stores user generated data into the same file.
So mixing up user-generated-content with prepopulated data is not was Apple wants us to do.
So far so good.
Separate my database into two and mark the store file with the prepopulated data with NSURLIsExcludedFromBackupKey = YES.
But what happens if the user wants to modify the data in that store, because he found a failure and wish to modify it.
Or myself make an online update available which modifies values with that store.
How do I cope with that.
Do I have to delete the store file, create a new one (now with NSURLIsExcludedFromBackupKey = NO) or store the database under /tmp or /Library/caches right from the beginning and move it into /Application Support (which is backed up automatically) but with the threat that my database is being removed by the system for some reason what is the case for /Library/caches?
It is a bit annoying that Apple will not allow you to backup prepopulated data if your app is of the kind where you could actually change the prepopulated data in the app. If the prepopulated database is big, I can however understand that they don't want your app to waste the user´s iCloud space with information that is already in the AppStore.
Woody has a good idea on the approach, but I'm not sure Apple would look away from the fact that you are actually wasting just as much space if you copy the prepopulated data to the user-backed-up DB on app startup.
What about something like this:
A: DB with pre-populated data, not backed up
B: DB with user added
data, backed up
When user make changes to object in A, crete a new row in B that "overrides" the row in A, for example by using the same ID or by having a column in the DB that tells the app which object in A should be replaced by the new row in B.
Whenever you need to update your app, you will replace DB A with new content and that's it. This could lead to conflicts with the data that the user has changed. You will have to decide whether the user data is more important than the updated data, and how to handle these conflicts (for example by trying to keep them both).
If you need to change the structure of DB B in an update, for example if you need to add a column, you will have to include an update routine in your app that detects that the user is having an old DB version and write code to migrate the user data to the new database on first startup after the update.
When you startup, if the user database is unpopulated you could copy the data across from the pre-populated datatabse, and maybe give the user an option to reset defaults which does the same again?
I've looked all over for an answer, but it seems like I'm missing something obvious. I've made a rather complex Core Data app before, but the answer to this question has eluded me for the past few months.
Here's the problem:
1) I have about 20 entities in my Model.
2) Some of these entities have user-editable objects, others have pre-loaded data
3) I would like to know if it's possible to update the pre-loaded entities with each new app update.
I know I can do this the "manual" way by specifying each updated attribute, but this is way too cumbersome. I want to just update all the pre-loaded entities once the user opens an updated version of the app. I don't want to touch the user-data.
Thank you so much for your help!
You could have a version number field in your schema which you can use to associate a version number with each record. If it has a value, it's a preload. Then for the preload stuff just insert the new data when the app opens, and then ignore/delete the old. Seems simple enough.
UPDATE:
The other alternative I believe is to separate your preloaded data into an entirely different data store. I have an app wherein I do this by delivering my preloaded data via a custom SQLite file, and user data in a CoreData store. I can do this because my preloaded data is read-only, which saves me from needing to copy the SQLite file into the documents directory. What this means is that, at every update, the new data file automatically overwrites the old by virtue of the app installation. The user's data is maintained as it should be.
Of course if your preloaded data is not read-only, then there's no way around the need to write code. In this case there's not much I can do for you, not having any more details about your problem.