Add encrypted SQLCipher WatermelonDB JSI

[ororsatti]

ideally i'd like to avoid adding to the non-JSI version since its going to be less and less supported as we progress with JSI in RN.

TODO:

• Add SQLCipher to Android
• Add an option to select sqlite build (sqlite3/sqlCipher - this seem to be a requirement on the last PR trying to add sqlcipher) on Android
• ADD SQLCipher to iOS
• Add an option to select sqlite build (sqlite3/sqlCipher - this seem to be a requirement on the last PR trying to add sqlcipher) iOS
• Change API to accept passphase.
• Add sqlcipher amalgamation to nozbe workspace (same method as sqlite and simdjson) @radex
• Fix iOS tests

[ororsatti]

@radex I can not seem to run the ios/android tests properly, any chance you help me with it?

[killerchip]

Hey guys,

Thanks for your great work on this, and thanks for the great library

Is this PR still alive? Is there still interest in Nozbe in adding encryption to the DB?
We are also looking into using WatermelonDB with encryption on native (Android mainly). But C++ is currently out of my league. Do you know how I can help?

I was able to make something work based on this PR #907, but of course, it does not support JSI.

@ororsatti, does your PR work? I just did a test, but it seems that the DB is not getting encrypted (Android).

[ororsatti]

Hey guys,

Thanks for your great work on this, and thanks for the great library

Is this PR still alive? Is there still interest in Nozbe in adding encryption to the DB?
We are also looking into using WatermelonDB with encryption on native (Android mainly). But C++ is currently out of my league. Do you know how I can help?

I was able to make something work based on this PR #907, but of course, it does not support JSI.

@ororsatti, does your PR work? I just did a test, but it seems that the DB is not getting encrypted (Android).

I'm using it in several production apps, so yep.
I might be able to help talk to me this evening:
[email protected]

[killerchip]

I'm using it in several production apps, so yep. I might be able to help talk to me this evening: [email protected]

@ororsatti thank you very much for your valuable help on this. Indeed your PR works as expected.
As we discussed it would be awesome if this could turn into a separate WMDB adapter.

@radex would it be preferable to make it into a separate adapter? Or just as an option to the base SQLite adapter as is with this PR?

[ororsatti]

I'm using it in several production apps, so yep. I might be able to help talk to me this evening: [email protected]

@ororsatti thank you very much for your valuable help on this. Indeed your PR works as expected.
As we discussed it would be awesome if this could turn into a separate WMDB adapter.

@radex would it be preferable to make it into a separate adapter? Or just as an option to the base SQLite adapter as is with this PR?

I don't think making it an adapter is the right decision.
An adapter is the middle layer, what stands between your app, and the underlying SQLite.
Since I am not changing the platform, nor the api, I don't see a reason to change the adapter here.
It should be as it is, a flag on which you raise if you want to use it, and pass password if you desire.

[ororsatti]

I'm using it in several production apps, so yep. I might be able to help talk to me this evening: [email protected]

@ororsatti thank you very much for your valuable help on this. Indeed your PR works as expected.
As we discussed it would be awesome if this could turn into a separate WMDB adapter.

@radex would it be preferable to make it into a separate adapter? Or just as an option to the base SQLite adapter as is with this PR?

You can think about it like it's a car.
If you change the engine, but as long as it has the same gear, i.e the same API, you don't have to learn manual.
Same here, the api is the same, so no need to change the adapter.