hi guys, I am trying to integrate sqldelight with ...

# touchlab-tools

[romtsn]

hi guys, I am trying to integrate sqldelight with sqlcipher on ios - I’ve gone through your article and did everything like suggested (building a static framework with sqlcipher pod as a dependency), but now am facing a weird issue - it looks like this works from code, so I can do some operations over a database (at least the last_changed_date in the file system changes), but when I try to open the db file with the db-browser or decode via sqlcipher-cli the password does not seem to work, so I cannot access the data.

Could this be due to the recent fix which is not yet released in sqliter? Or is the db encrypted with some different algorithm than the default one for sqlcipher 4.+? Here is my database config just in case:

val dbConfig = DatabaseConfiguration(
            name = "name.db",
            version = MyDb.Schema.version,
            create = { connection -> wrapConnection(connection) { MyDb.Schema.create(it) } },
            upgrade = { connection, oldVersion, newVersion ->
                wrapConnection(connection) {
                    MyDb.Schema.migrate(it, oldVersion, newVersion)
                }
            },
            basePath = customDirPath,
            key = key,
            journalMode = JournalMode.DELETE
        )

Thanks!

[Sam Hill]

You will need the fix you linked for setting the key to work, though in my experience you will get an exception when creating the db, so if you’re still able to create and use the db I would guess that sqlcipher isn’t linking and it’s using apple’s encryption

[Sam Hill]

in XCode, try taking a look at your target build settings and make sure that in “Other Linker Flags” you have -framework "SQLCipher" which should be inherited from the pod project and no -lsqlite3

[romtsn]

thanks Sam, I’ve checked and actually both of them are present.. I suspect it’s because I have a direct dependency in the project to SQLCipher as well (besides the one in the KMP module), so it probably overrides the KMP’s one?

[romtsn]

so it’s like this:
project:
<- SQLCipher
<- KMP module <- SQLCipher

[romtsn]

I am n00b when it comes to pods, so bear with me 🙂

[romtsn]

so I’m trying to integrate the kmp module into the existing project which is already using cipher, and trying to use them side-by-side (just having one table for PoC in kotlin/sqldelight) to give you full context

[Sam Hill]

Sure, I’m fairly new to them too. When you add the pod in gradle and run gradlew podspec it adds the cipher pod as a dependency in your podspec. This makes it available in xcode, so I think you should be able to remove the top level instance of SQLCipher. I don’t think it will cause any issues though unless you get versions mismatching. If you do still have sqlite3 in you linker flags though I would try removing that to make sure it links with SQLCipher instead

[romtsn]

So just remove sqlite3 from this Other Linked flags? I will try, thanks 👍

[Sam Hill]

yeah. unfortunately that will still get you running in to the query bug in sqliter. Looks like an update for kotlin 1.4 was just published which would include the fix but it would take a while to get everything updated for 1.4. @kpgalligan would have a better idea on whether you could build sqliter locally with the fix included

[romtsn]

I actually tried to build it locally and publish to local maven, then defined a strict version so gradle could pick it up instead of the one bundled with sqldelight, but then ran into a similar issue but for the databasemanager class.. not sure what’s the reason

[romtsn]

thanks a ton @Sam Hill, that worked - I am able to open the db file via db-browser now. On subsequent connection openings though I get the following error:

Uncaught Kotlin exception: kotlin.Exception: android/database/sqlite/SQLiteDatabaseCorruptException - file is not a database (code 26): , while compiling: PRAGMA journal_mode

Could it be related to your fix?

[Sam Hill]

I don’t think that’s related to my fix. Based on the error it seems that it’s failing to decrypt the db. I’d look to make sure that the same version of SQLCipher is being used and that the key pragma is being set before trying to do anything else with the db