Skip to content

sqlcipher_export() and SQLiteOpenHelper conflict #71

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
commonsguy opened this issue Nov 7, 2012 · 2 comments
Closed

sqlcipher_export() and SQLiteOpenHelper conflict #71

commonsguy opened this issue Nov 7, 2012 · 2 comments

Comments

@commonsguy
Copy link
Collaborator

Your test case for sqlcipher_export() uses SQLiteDatabase directly. However, when I try using it in conjunction with your SQLiteOpenHelper, I run into some issues. Specifically, the metadata that Android stores for version info does not seem to make it over to the encrypted database. As a result, when I turn around and try to use the encrypted database with SQLiteOpenHelper, Android tries upgrading the database from version 0 to 1, running through the SQLiteOpenHelper onCreate() logic again, which should not be necessary.

Here is the encrypt-my-unencrypted-database method that I am using:

static void encrypt(Context ctxt) throws IOException {
 SQLiteDatabase.loadLibs(ctxt);

 File dbFile=ctxt.getDatabasePath(DATABASE_NAME);
 File legacyFile=ctxt.getDatabasePath(LEGACY_DATABASE_NAME);

 if (!dbFile.exists() && legacyFile.exists()) {
  SQLiteDatabase db=
      SQLiteDatabase.openOrCreateDatabase(legacyFile, "", null);

  db.rawExecSQL(String.format("ATTACH DATABASE '%s' AS encrypted KEY '%s';",
                              dbFile.getAbsolutePath(), PASSPHRASE));
  db.rawExecSQL("SELECT sqlcipher_export('encrypted')");
  db.rawExecSQL("DETACH DATABASE encrypted;");
  db.close();
  legacyFile.delete();
 }
}

Thoughts?

Thanks!

@developernotes
Copy link
Member

Hi Mark,

The user_version PRAGMA is explicitly excluded from the sqlcipher_export convenience function. There certain instances where migrating the current user_version is not preferable. The sqlcipher_export function does not require that the attached database be empty, thus you could legitimately have an existing user_version that you are migrating into and do not want to change.

In cases where you do want to carry over the user_version, you can do this manually by capturing the value with getVersion(), setting it after your migration with setVersion(...).

@commonsguy
Copy link
Collaborator Author

OK, that works. This, and the "is rawExecSQL() stable for long-term use", probably deserve a spot in the documentation, at some point.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants