一.簡(jiǎn)介
我們?cè)陂_發(fā)應(yīng)用的時(shí)候，存儲(chǔ)數(shù)據(jù)可能會(huì)用到數(shù)據(jù)庫(kù)。第一個(gè)版本時(shí)所設(shè)計(jì)的數(shù)據(jù)庫(kù)結(jié)構(gòu)，如果在以后的app版本中需要增加業(yè)務(wù)邏輯，數(shù)據(jù)庫(kù)的表可能要做相應(yīng)的修改，那么原來的數(shù)據(jù)庫(kù)結(jié)構(gòu)就不能用了，這時(shí)就需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行升級(jí)。
二.升級(jí)方案
1.讓用戶將應(yīng)用卸載然后再安裝最新版本的app
2.對(duì)數(shù)據(jù)庫(kù)進(jìn)行升級(jí)，對(duì)于第一種方案，用戶卸載老版本就會(huì)造成數(shù)據(jù)丟失，這樣對(duì)于用戶的體驗(yàn)性極差，不到萬不得已的時(shí)候不要做。我們傾向于選擇第二項(xiàng)方案。
三.不同版本升級(jí)分析
3.1.Version1.0
當(dāng)我們開發(fā)第一個(gè)版本數(shù)據(jù)庫(kù)的時(shí)候，SQLiteOpenHelper的繼承類里會(huì)走onCreate()方法，即 —->v1.0 走onCreate()，這時(shí)候并不涉及更新的方法。
3.2.Version2.0
當(dāng)我們開發(fā)到第二個(gè)數(shù)據(jù)庫(kù)版本的時(shí)候，分兩種情況：
(1) 用戶從1.0版本升級(jí)到2.0版本 SQLiteOpenHelper的繼承類里會(huì)走onUpgrade()方法,不走onCreate()方法。即v1.0—->v2.0 走onUpgrade()；
(2) 如果是用戶直接安裝v2.0 ， SQLiteOpenHelper的繼承類里會(huì)走onCreate()方法,不走onUpgrade()方法。即 —->v2.0 走onCreate()
3.3.Version3.0
(1) 用戶從1.0版本升級(jí)到3.0版本 ，SQLiteOpenHelper的繼承類里會(huì)走onUpgrade()方法,不走onCreate()方法。即v1.0—->v3.0 走onUpgrade()
(2) 用戶從2.0版本升級(jí)到3.0版本 ，SQLiteOpenHelper的繼承類里會(huì)走onUpgrade()方法,不走onCreate()方法。即v2.0—->v3.0 走onUpgrade()
(3) 如果是用戶直接安裝3.0 ，SQLiteOpenHelper的繼承類里會(huì)走onCreate()方法,不走onUpgrade()方法。即 —->v3.0 走onCreate()
如下圖:
只要是第一次安裝或者第一個(gè)數(shù)據(jù)庫(kù)版本的都走onCreate()方法，而不走onUpgrade()方法，從低版本升級(jí)到高版本的都走onUpgrade()方法而不走onCreate()方法。
四.代碼分析
4.1第一個(gè)數(shù)據(jù)庫(kù)版本
只走onCreate()，所以我們可以把創(chuàng)建表的方法寫在這個(gè)方法里。
另外需要注意的是，我們要把創(chuàng)建SQLiteOpenHelper子類的地方寫成單例模式，這樣可以避免重復(fù)創(chuàng)建，出現(xiàn)問題。
此時(shí)的DataBaseConfig.DATABASE_NEW_VERSION 為1
點(diǎn)擊獲取低版本信息按鈕
如果以后的需求改變，需要往數(shù)據(jù)庫(kù)里加字段或者改字段，需要升級(jí)數(shù)據(jù)庫(kù)。
4.2第二個(gè)數(shù)據(jù)庫(kù)版本
如果是從v1.0升級(jí)到v2.0，則走onUpgrade,如果是直接安裝v2.0，則走onCreate()
4.2.1. 比如從v1.0升級(jí)到v2.0 需要增加字段
此時(shí) DataBaseConfig.DATABASE_NEW_VERSION 為2 ，DataBaseConfig.DATABASE_FIRST_VERSION為1
版本2比版本1中新增了sex,和address字段，比版本1多了兩項(xiàng)，由于代碼中默認(rèn)的性別是女，所以前三個(gè)的性別是女。
????? 注：還要再處理onCreate(),因?yàn)橛脩艨赡苁侵苯影惭bV2.0
????? 有兩種方法：
（1）執(zhí)行舊版數(shù)據(jù)庫(kù)sql,則后面還要調(diào)用onUpgrade
（2）執(zhí)行新版數(shù)據(jù)庫(kù)sql，不需要調(diào)用onUpgrade
4.2.2. 第二個(gè)版本數(shù)據(jù)庫(kù)需要新增并修改字段
??????? 注:比如從v1.0升級(jí)到v2.0 需要增加字段
??????????? 新增sex,address字段，修改age–>sign
此時(shí) DataBaseConfig.DATABASE_NEW_VERSION 為2 ，DataBaseConfig.DATABASE_FIRST_VERSION為1
從圖中可以看出，已經(jīng)將age選項(xiàng)修改為簽名sign了，增加了sex,address兩個(gè)選項(xiàng)。
處理onCreate()方法同增加字段里的處理一致。
五.總結(jié)
本文總結(jié)了數(shù)據(jù)庫(kù)升級(jí)的相關(guān)內(nèi)容，包括為什么要升級(jí)數(shù)據(jù)庫(kù)，怎么升級(jí)數(shù)據(jù)庫(kù)，新增字段和修改字段怎么處理，如有發(fā)現(xiàn)問題，歡迎討論，共同學(xué)習(xí)。
GreenDao數(shù)據(jù)庫(kù)升級(jí)
不斷版本迭代，一些數(shù)據(jù)庫(kù)中的結(jié)構(gòu)也要發(fā)生改變、優(yōu)化，但如果貿(mào)然修改數(shù)據(jù)庫(kù)的版本號(hào)，只會(huì)把舊數(shù)據(jù)庫(kù)的數(shù)據(jù)刪除，再重新創(chuàng)建新表，導(dǎo)致舊數(shù)據(jù)丟失，這樣的做法明顯是不可取的。于是我們需要數(shù)據(jù)庫(kù)的升級(jí)，也要保證舊數(shù)據(jù)保留。
新建MyDevOpenHelper，繼承DaoMaster.DevOpenHelper，重寫onUpgrade(Database db, int oldVersion, int newVersion)方法，在該方法中使用MigrationHelper進(jìn)行數(shù)據(jù)庫(kù)升級(jí)以及數(shù)據(jù)遷移。
MigrationHelper由網(wǎng)上一位大神攥寫，鏈接：https://stackoverflow.com/questions/13373170/greendao-schema-update-and-data-migration/30334668#30334668，有兩個(gè)版本，后面一個(gè)適合GreenDao3.0版本，自行選用。
注意：表中的數(shù)據(jù)類型是基礎(chǔ)數(shù)據(jù)類型的包裝類，用Long而不是long，否則會(huì)報(bào)錯(cuò)。合并數(shù)據(jù)后，舊數(shù)據(jù)表中沒有的字段值或賦null值。原來的參與數(shù)據(jù)庫(kù)的實(shí)體類需要重新生成構(gòu)造方法和getter/setter。
build項(xiàng)目后，排除所有異常后，在build.gradle文件中配置的greedao中修改數(shù)據(jù)庫(kù)版本號(hào)，遞增1
