Hi @justinclift - excellent work. I just gave it a try on windows and it worked very well for me. It’s nice to see a new windows option out there for SQLCipher database management. Let us know when you release the final version and we’ll update our article on management interfaces to indicate that Windows is now supported. Out of curiosity, will you supply signed builds for the final releases? Windows SmartScreen under Windows 10 won’t install the package without a manual override, which might be either concerning or confusing to users.
With regard to the question about SQLITE_TEMP_STORE, we’ve typically used 2 since it forces everything to memory by, but still allows a developer or user to override that decision at runtime using a pragma if necessary. This can be useful in some circumstances, for instance:
- If there is limited memory available on the system, and there is an explicit decision to use temp storage on disk
- You are using SQLCipher to work with unencrypted databases (as is often the case when SQLCipher is compiled into an application)
- If you are dealing with truly large data sets where in memory temp tables aren’t feasible, and again there is an explicit decision to use on disk temp storage
This approach satisfies the criteria of having the database library never write secure data in an unencrypted form to permanent storage without explicit consent without locking the developer in.
That said, for the vast majority of typical SQLCipher use cases, SQLITE_TEMP_STORE=3 is just as good and perhaps better. We’ll consider this a bit further, and may adjust our recommendations in the future.