Call sqlite3_errmsg() directly in sqlite3_soci_error ctor instead of
doing it in multiple places in the backend code.
Throw soci_error when there is no SQLite3-specific information
associated with the error.
Update the documentation to make it more clear that both
sqlite3_soci_error and soci_error must be caught.
Use sources from the submodule to create soci_sqlite3_builtin library.
Recommend cloning with --recurse-submodule to ensure that the submodule
is available and update AppVeyor CI to initialize submodules too.
Add "BUILTIN" dependency mode to soci_define_backend_target() and use it
for SQLite3 backend.
Note that because SQLite3 source is C, and not C++, this language needs
to be explicitly added to CMake project() function, otherwise C files
are just silently ignored.
This commit is best viewed ignoring whitespace-only changes.
Use these functions instead of directly using SQLite3 ones in the test.
This makes no real difference, but allows to provide the implementation
of these functions in SOCI SQLite3 backend itself and so works even when
SQLite3 library is linked statically into this backend and is not linked
into the test.
Since SQLite doesn't have a type system, we have to always be prepared
to select huge numbers, even if the "type" is e.g. int8.
To do that, we overwrite the exchange type (e.g. in row based APIs) to
always be (u)int64 for integers to avoid over-/underflows.
Update the documentation to explain this SQLite peculiarity and add a
test verifying that this behaves as expected.
Fixes#1190.
Closes#1217.
Don't duplicate the code for parsing space-separated possibly quoted
words in SQLite3 backend but just use the common function for it too.
Also correct handling of some boolean parameters, where previously
specifying any value, even "0" or "false", would enable it and document
the exact values accepted for them.
Add tests checking that parsing connection string works as expected.
This allows to avoid creating the database file if it doesn't already
exist as it may sometimes (often?) be undesirable, e.g. when it's
supposed to have been already created and its schema initialized, as
creating an empty database is not really helpful in this case.
Allow enabling foreign key checking, which is disabled by default in the
current SQLite versions, for the applications that need it using the
appropriate SQLite pragma if the corresponding connection string
parameter is specified.
Closes#968.
Vadim Zeitlin