Try to figure out why TRUE/FALSE literals aren't working as expected about nim-sqlcipher

[michaelsbradleyjr]

Investigation ongoing in #25.

What I wrote in discord chat:

What I find on all platforms is that it's fine to create a BOOLEAN column using a bool literal (TRUE, FALSE, true, false).

If you do an insert into that column using Nim bool true or false or int 1 or 0, things work as expected.

However, sqlite will let you insert a string, doing so doesn't cause an error. Then when you get that value back from a query, if you do db.fromValue(..., bool) it will blow up.

While we could add string->boolean logic for fromValue for bool, I think it's better to leave it as. What I'm thinking is that on the Nim side if someone inserts a string into a boolean column, then that's really a mistake on their part, they should have used a Nim bool or int, and the error they get at runtime [when running a query] will signal that mistake.

I'm not sure if/how we could add something on the Nim side that helps to ensure that when you put values into the database you're putting the right types with respect to the column types.

Another thing I'm not sure about is if with various changes to master that landed recently we've solved the problem where the column type itself would be wrong when a column is created as BOOLEAN with a default value that's a bool literal. Or maybe we simply misunderstood what was happening re: what I describe above. @emizzle I'll be grateful if you can poke at this and let me know what you think.

[michaelsbradleyjr]

I was unable to reproduce the problem, i.e. BOOLEAN columns with default value spec'd as a boolean literal are working as expected on all platforms tested, and regardless of whether libsqlcipher is linked as a static or shared library.