一.簡介
我們在開發(fā)應用的時候平窘，存儲數(shù)據(jù)可能會用到數(shù)據(jù)庫吓肋。第一個版本時所設計的數(shù)據(jù)庫結構，如果在以后的app版本中需要增加業(yè)務邏輯瑰艘，數(shù)據(jù)庫的表可能要做相應的修改是鬼，那么原來的數(shù)據(jù)庫結構就不能用了，這時就需要對數(shù)據(jù)庫進行升級紫新。
二.升級方案
1.讓用戶將應用卸載然后再安裝最新版本的app
2.對數(shù)據(jù)庫進行升級均蜜，對于第一種方案，用戶卸載老版本就會造成數(shù)據(jù)丟失弊琴，這樣對于用戶的體驗性極差兆龙，不到萬不得已的時候不要做杖爽。我們傾向于選擇第二項方案敲董。
三.不同版本升級分析
3.1.Version1.0
當我們開發(fā)第一個版本數(shù)據(jù)庫的時候，SQLiteOpenHelper的繼承類里會走onCreate()方法慰安，即 —->v1.0 走onCreate()腋寨，這時候并不涉及更新的方法。
3.2.Version2.0
當我們開發(fā)到第二個數(shù)據(jù)庫版本的時候化焕，分兩種情況：
(1) 用戶從1.0版本升級到2.0版本 SQLiteOpenHelper的繼承類里會走onUpgrade()方法,不走onCreate()方法萄窜。即v1.0—->v2.0 走onUpgrade()；
(2) 如果是用戶直接安裝v2.0 撒桨， SQLiteOpenHelper的繼承類里會走onCreate()方法,不走onUpgrade()方法查刻。即 —->v2.0 走onCreate()
3.3.Version3.0
(1) 用戶從1.0版本升級到3.0版本 ，SQLiteOpenHelper的繼承類里會走onUpgrade()方法,不走onCreate()方法凤类。即v1.0—->v3.0 走onUpgrade()
(2) 用戶從2.0版本升級到3.0版本 穗泵，SQLiteOpenHelper的繼承類里會走onUpgrade()方法,不走onCreate()方法。即v2.0—->v3.0 走onUpgrade()
(3) 如果是用戶直接安裝3.0 谜疤，SQLiteOpenHelper的繼承類里會走onCreate()方法,不走onUpgrade()方法佃延。即 —->v3.0 走onCreate()
如下圖:
只要是第一次安裝或者第一個數(shù)據(jù)庫版本的都走onCreate()方法现诀，而不走onUpgrade()方法，從低版本升級到高版本的都走onUpgrade()方法而不走onCreate()方法履肃。
四.代碼分析
4.1第一個數(shù)據(jù)庫版本
只走onCreate()仔沿，所以我們可以把創(chuàng)建表的方法寫在這個方法里。
另外需要注意的是尺棋，我們要把創(chuàng)建SQLiteOpenHelper子類的地方寫成單例模式封锉，這樣可以避免重復創(chuàng)建，出現(xiàn)問題膘螟。
此時的DataBaseConfig.DATABASE_NEW_VERSION 為1
點擊獲取低版本信息按鈕
如果以后的需求改變烘浦，需要往數(shù)據(jù)庫里加字段或者改字段，需要升級數(shù)據(jù)庫萍鲸。
4.2第二個數(shù)據(jù)庫版本
如果是從v1.0升級到v2.0闷叉，則走onUpgrade,如果是直接安裝v2.0，則走onCreate()
4.2.1. 比如從v1.0升級到v2.0 需要增加字段
此時 DataBaseConfig.DATABASE_NEW_VERSION 為2 脊阴，DataBaseConfig.DATABASE_FIRST_VERSION為1
版本2比版本1中新增了sex,和address字段握侧，比版本1多了兩項，由于代碼中默認的性別是女嘿期，所以前三個的性別是女品擎。
????? 注：還要再處理onCreate(),因為用戶可能是直接安裝V2.0
????? 有兩種方法：
（1）執(zhí)行舊版數(shù)據(jù)庫sql,則后面還要調(diào)用onUpgrade
（2）執(zhí)行新版數(shù)據(jù)庫sql，不需要調(diào)用onUpgrade
4.2.2. 第二個版本數(shù)據(jù)庫需要新增并修改字段
??????? 注:比如從v1.0升級到v2.0 需要增加字段
??????????? 新增sex,address字段备徐，修改age–>sign
此時 DataBaseConfig.DATABASE_NEW_VERSION 為2 萄传，DataBaseConfig.DATABASE_FIRST_VERSION為1
從圖中可以看出，已經(jīng)將age選項修改為簽名sign了蜜猾，增加了sex,address兩個選項秀菱。
處理onCreate()方法同增加字段里的處理一致。
五.總結
本文總結了數(shù)據(jù)庫升級的相關內(nèi)容蹭睡，包括為什么要升級數(shù)據(jù)庫衍菱，怎么升級數(shù)據(jù)庫，新增字段和修改字段怎么處理肩豁，如有發(fā)現(xiàn)問題脊串，歡迎討論，共同學習清钥。
GreenDao數(shù)據(jù)庫升級
不斷版本迭代琼锋，一些數(shù)據(jù)庫中的結構也要發(fā)生改變、優(yōu)化祟昭，但如果貿(mào)然修改數(shù)據(jù)庫的版本號缕坎，只會把舊數(shù)據(jù)庫的數(shù)據(jù)刪除，再重新創(chuàng)建新表从橘，導致舊數(shù)據(jù)丟失念赶，這樣的做法明顯是不可取的础钠。于是我們需要數(shù)據(jù)庫的升級，也要保證舊數(shù)據(jù)保留叉谜。
新建MyDevOpenHelper旗吁，繼承DaoMaster.DevOpenHelper，重寫onUpgrade(Database db, int oldVersion, int newVersion)方法停局，在該方法中使用MigrationHelper進行數(shù)據(jù)庫升級以及數(shù)據(jù)遷移很钓。
MigrationHelper由網(wǎng)上一位大神攥寫，鏈接：https://stackoverflow.com/questions/13373170/greendao-schema-update-and-data-migration/30334668#30334668董栽，有兩個版本码倦，后面一個適合GreenDao3.0版本，自行選用锭碳。
注意：表中的數(shù)據(jù)類型是基礎數(shù)據(jù)類型的包裝類袁稽，用Long而不是long，否則會報錯擒抛。合并數(shù)據(jù)后推汽，舊數(shù)據(jù)表中沒有的字段值或賦null值。原來的參與數(shù)據(jù)庫的實體類需要重新生成構造方法和getter/setter歧沪。
build項目后歹撒，排除所有異常后，在build.gradle文件中配置的greedao中修改數(shù)據(jù)庫版本號诊胞，遞增1
