Right now I use versioning to make any changes in a database. But it brings some problems. For example it's hard to merge a feature branch with a new db version into a master/dev where somebody also added a new version.
So my question:
Is it safe to change db in a single xcdatamodel without adding new versions? I tried so and it works but everywhere on the internet I see warnings that you must not do that.
iOS9+.
I found this: https://stackoverflow.com/a/37264096/5328417 but it's without a proof
As #pbasdf noted, since iOS 9 you can do a lightweight migration without adding any new model version. Source model (previous model version) is cached to store and used as a last ditch effort during lightweight migration.
I am using this feature in my own apps successfully. Although I was not able to find this documented. Just that WWDC video (18'15 Model Caching) mentioned. This is exactly the reason why Core Data is so mysterious sometimes..
If your app is in development stage then you may use one model without versioning.
But if it is release on the App Store then you have to create the versions when you make changes (such as adding a new attribute, adding a new entity, renames attributes etc.). Otherwise, Core Data won't perform lightweight migration.
I've gt a question to ask. Currently my production CoreData version is 1.0. Then , since i've gt a new class/property to add, i've increased version to 1.1 and released this version for tester.
Now, I need to add another property to CoreData.
1) So, should I create a new model version or I can straight away modify current CoreData(v1.1).
Note that the build with v1.1 CoreData hasn't been released to production yet..just to tester.
2) If need to add new version (v1.2) to accommodate the new property, will it have any affect when i released it to production build?
3) If can straight away modify, will current development version that tester has installed crash when they update to new version that has the new property added?
You can modify v1.1, but then tester will have to delete the app, as the app may not be able to open the coredata or have inconsistencies. To avoid this, tester will have to delete the app,and he might miss issues(if any) due to this structure change, to catch only in production. So you should be changing the version.
It wont cause any issues, if the versioning and migration is done properly.
Yes, there could be inconsistencies and instances where the app won't be able to open the coredata.
In order to avoid CoreData versioning for testing purpose you can modify the current CoreData version and tell your tester to delete the previous build before installing new one.
Otherwise you have to perform migration every time you change the DB schema in order to avoid inconsistency.
You can do the versioning before sending it to the production environment.
Hi I'm wondering if there is any method that is called when an app is updated similar to androids onUpgrade(). I'm using a SQLite database in my app and the schema has changed a lot in the new version.
If the old version is on the phone and I run the new version through Xcode. It will not work as the old tables do not correspond. The app syncs to the server so I am not worried about the users data. So I could drop all the tables on update.
There is no API to indicate an upgrade. You need to determine this yourself. There are many possible approaches.
What I do in my sqlite-based app is I have a meta-data table in the database. This contains a schema version number. I check this against a hardcoded version number I put in the code. If they are different then I know the database needs to be updated. I provide sql scripts in my app that can update any prior schema version to the current version. I simply run the script that matches the version shown in the database.
This approach allows me to deal with users that haven't upgraded in a while and the schema may need to go through multiple revisions.
Can I do the following?
Start with v1.0 of an app. Version data model, designate new version as active schema
Set correct options in appDelegate for creating NSPersistentStoreCoordinator using lightweight migration
Make simple changes to the model and update classes. Compile and verify that everything works.
Make another change to the data model without changing the version, and again update the classes
Of course when I run, the data model will be incompatible since I have changed it without versioning. But since I will not be shipping the intermediate version, my suspicion is that the data migration should work fine when updating from v1.0 to the double-updated data model.
Is this accurate?
It will work as long as the following are true:
You have created a new model version for each of these steps; so in your example above you should have three at the end: original, intermediate, final.
The app must be able to do a lightweight migration from 1 to 3. If it cannot it will not go through 2 if the data on disk is still in the structure of 1.
If all of that is true then it will work. And you can even go so far as to not ship v2 in the final build (although they are small and it is usually not worth the effort).
During development my recommendation is to always keep the v1 data around, only change v2 and remigrate every time you need to adjust v2. Then there is no intermediate to deal with. However that is not always possible when dealing/working with beta testers.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is a version control system? How is Git useful?
I am new to Ruby on Rails platform, and so this may sound a little naive.
Why and when do we store our work in a version control system like git?
I mean what is the advantage of it ! Can't we just keep it in our local machine ?
Advantages for using git/source control:
For yourself
Remembering what you have coded and when you did it
Being able to compare what you did to previous work
Allow you to work on something experimental, and if it doesn't work switch it back to where it was before
Working with a team
It makes working with others easier - you can work on the same file at the same time and really easily combine your changes.
It will allow you to work in multiple locations and easily have the most recent code
It will help in deploying your code to a server
Git workflow for teams
Git branching model
When to store or commit your work:
You want to do this each time you finish on a particular "idea" or piece of work you are working on. This means you can have a useful commit message and can go back im time to that feature you just wrote or that bug that you just fixed.
How often and when to commit
Reasons for using Git over other source control
Its fast (switching branches is really fast and you have a local copy, so you dont have to communicate to a server for a lot of things unless you want to push or pull changes to the server)
Yes, this seems quite naive, but every question is worth asking!
First of all, using a SCM (software configuration manager) will greatly help you in a number of scenarios:
trying out experimental features without touching the main code
developing several independent ideas at the same time
recovering from failed changes, whenever they are complex and include changes in multiple files.
tracking the exact code used in a specific release, to fix a reported bug.
This doesn't even start to touch the infinite amount of work you'd have if working in a team without SCM.
And using a SCM doesn't involve network, git and any other distributed SCM is equally valid for local development, as the repository is all in your computer. You just don't pull and push.
The choice is not whether to store code in version control versus storing it on your local machine. In fact, unlike other version control systems (like Subversion, known also as svn), Git does not need a server to run.
Version control makes it easy to understand what changes were made, view and restore older versions of files, and even import changes from one version to another.
RETRIEVAL: Imagine you are working on a project on your own. You delete an old file you don't think you need anymore. A week later, you realize that the file was very important. If you use version control, you can see what the file looked like just before you deleted it, and restore it as if it were never deleted. Also, most changes committed to version control contain messages; if you join a team and the previous developer used version control (with good commit messages) you can get an easier context for when changes were made and why.
MULTIPLE RELEASES (BRANCHES): Now imagine that your software is version 1.0. You're busy working on version 2.0, but someone files a bug. What can you do? With version control, you can zoom back to version 1.0, make some changes, and then create version 1.0.1. Most version control platforms even let you apply the changes made in version 1.0.1 onto the work you're doing in version 2.0.
MULTIPLE FEATURES: Your software is so successful, you start releasing it weekly. However, not every feature is ready for release. First you start working on the widget feature, than you start working on the doodad feature. If you work on both of these at the same time, you may have two half-coded features in development at the same time, and nothing is working well enough to release. With version control, once one of the features is done, you can merge it into the "main" release as if you wrote it in one day.
COLLABORATION: Finally, now imagine that you're in a team of five or six developers all working on the same code. Naturally, you don't want to email zip files of code back and forth, especially when every developer is working on a separate feature. With version control, you can have a single history, to which all of your developers write and read.
Naturally, some of the above can be done by keeping multiple copies of the same files in different adjacent directories. The benefit of version control software is that it can handle much of the work for you while avoiding duplicating the same file over and over on your disk.
Long winded--sorry--but hope that helps!
Advantages of using git:
Code will be safe in remote repo, even if the local project crashes
You can try out new things without worrying about previous works as they can retrieved
The code can accessed from anywhere in the world
When working in team, all the work will be stored in a single place so that it will be accessible to everybody in your team
Each and every change can be tracked easily, who did it and when they did it
Deployment of application will more easier
You can have multiple versions/branches so that it will be easy for you to identify the new features added to the application in every version
you see #arulmr, #kieran-andrews, #Jeff and #rewritten that post many advantages but still if you want learn more in details you can see below links
1) http://git-scm.com/book/ch8-1.html
2) http://www-oss.fnal.gov/~mengel/git_vs_subversion.html.bak
3) https://git.wiki.kernel.org/index.php/GitSvnComparison
4) http://www.wikivs.com/wiki/Git_vs_Subversion #History, Architecture, Licensing, Performance, Features of git and svn
now the difference between git and subversion
1) http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/