Management and implementation of Android SQLite database version upgrade

Management and implementation of Android SQLite database version upgrade

We know the construction method of sqliteopenhelper:

The last parameter in represents the version number of the database. When the new version number is greater than the current version, the method will be called:

Therefore, our focus is to realize the management of SQLite database version upgrade in this method

At the beginning of our project, the first version of sqliteopenhelper was written as follows:

A few days later, according to the project requirements, a student table needs to be added, so the second version of databaseopenhelper appears:

Compared with version 1, there are three modifications in version 2:

The version number of 1 has changed to 2

2. Add the code db.execsql (create_student) in oncreate () method; Create student table

Because some users don't have the first version of app at all, they download the second version of APP directly from the market. So of course oncreate() will be executed instead of onupgrade()

3. It is processed in onupgrade(): when OldVersion is 1, call db.execsql (create_student); Create the student table because some users already have the first version of APP on their mobile phones, they will execute onupgrade() instead of oncreate() when upgrading the app to the second version

Through such processing, the student table will be generated when using the second version of APP in different situations

Another month later, according to the project change, a field genderid needs to be added to the person table, so the third version of databaseopenhelper appears:

Compared with version 2, there are three modifications in version 3:

1 changed create_ The person statement adds a field genderid to the modified statement

Similar to the previous description, some users directly download the third version when installing the app for the first time

2. The revision number is 3

It deals with the situation that users upgrade from the first version or the second version to the third version (see the following analysis)

3. It is handled in the onupgrade () method: when the OldVersion is 2, call db.execsql (alter_person); Modify the person table and add the genderid field

It deals with the situation that users upgrade from the second version to the third version (see the following analysis)

Note a question: why does the switch statement here not break in each case???

This is to ensure that each database upgrade will be executed during cross version upgrade.

For example, if you upgrade from version 2 to version 3, case 2 will be executed.

For example, if you upgrade directly from the first version to the third version, case 1 will be called. Because there is no break, you will penetrate the switch statement and execute case 2 statement to continue the upgrade, so as to ensure that the upgrade in all versions of data will be executed to.

If you have any questions, please leave a message or go to the community of this site for exchange and discussion. Thank you for reading. I hope it can help you. Thank you for your support to this site!