don't skip .sql upgrade scipts after a forced upgrade if the bundled database file is not the latest version #109
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Due to an unclosed database
…s version is lower than the desired destination (mNewVersion)
ranaparamveer
pushed a commit
to ranaparamveer/android-sqlite-asset-helper
that referenced
this pull request
Jun 26, 2018
|
I'm maintaining the project here: Most of the open issues in this original repo are resolved over there. If you still find any issue please feel free to report there. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I don't always update the bundled .db file when I add a new schema version but instead I add an upgrade script .sql file (e.g. database.db_upgrade_2-3.sql) and accodingly increment (e.g. 2->3) the version parameter when calling the super constructor
SQLiteAssetHelper(...).This way existing installs use the .sql script as usual and new installs copy the bundled database.db (version 2) and then execute the .sql upgrade on top of that.
I found a problem when I use setForcedUpgrade(2), now updates from version 1 to 3 would replace the old version 1 database with the bundled version 2 (like expected), but not apply the version 3 upgrade .sql file and instead just set the version to 3.
I found that the code in
getWritableDatabase()blindly overrides the version of the newly copied database to be the latest version mNewVersion that had been defined by calling the super constructor.I based this PR on top of #87 because that is also related to using setForcedUpgrade().
The main change in this PR is to remove the line
db.setVersion(mNewVersion);in order to still trigger the version check and upgrade using .sql files if the bundled sqlite.db file is "outdated".