Use "_s" versions of the standard C functions if possible/simple to do
and disable deprecation warnings explicitly in a couple of places where
this could not be done instead of disabling them globally.
Also stop using strcpy() entirely and use strncpy() instead.
See #1268.
Try to classify all the possible SQLite result codes using SOCI
error_category enum.
In particular, this allows to detect connection and permission errors.
Update the unit test to test the error category too.
Don't use CHECK_THROWS_WITH(), it's convenient but not very flexible,
while an explicit try/catch will allow us to add more checks on the
exception object in the upcoming commits.
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.
The unit test relies on failing to insert "a" into an integer column but
SQLite is perfectly fine with doing this by default, so use an explicit
CHECK constraint to prevent this from succeeding and to make it behave
in the same way as the other databases.
SQLite documentation states that it can change in the future and it's
simple enough to turn it off explicitly, so do it.
Also combine 2 very similar tests in a single one and use 2 sections for
them instead.
No real changes.
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 compile them once, instead of doing it for every backend:
while this doesn't matter for the CI builds, recompiling common-tests.h
a dozen times enormously slowed down local builds using all backends.
Now it is compiled only once, as test-common.cpp, and all the other
tests (except for the "empty" one) just link with the resulting library.
Also extract some parts of this file into separate headers, that can be
included only by the tests that actually need them.
Note that the entire test-common.cpp probably ought to be split into
multiple files, to speed up its build too, but this can be done later.
This is the only place where they're used so far and it doesn't make
sense to compile them many times over when building the tests for the
other backends.
If these helpers are needed in the other backends tests, we should
extract them into their own header and include it as necessary.
Use type-appropriate names for the columns, which are still interpreted
in the same way as just "INTEGER" by SQLite3 itself, but can be mapped
back to the suitable types when reading from the database in SOCI.
Closes#1120.
Despite previously assumed and tested, most of the databases support
storing the various unsigned integer values. The checks for it in the
tests are therefore obsolete.
Only Firebird and SQLite seem to have a problem with storing UINT64_MAX.
The retrieval of it in a sorted result set with multiple other values
shows that the value is stored as a signed integer in the database.
The older read(...) and write(...) function, which take backend-specific
offsets rather than uniformly taken 0-based offsets (as is the case for
the *_from_start(...) functions), are now implemented in terms of their
*_from_start counterpart.
All test cases have been adapted to now prefer using the *_from_start
functions over the old counterparts.
Return the ID used for the given table instead of the last ID inserted
in any database table, which could be very different.
This relies on using internal sqlite_sequence table that is used by
AUTOINCREMENT.
Co-authored-by: Vadim Zeitlin <vz-soci@zeitlins.org>
Closes#971.
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.
SQLite doesn't have any specific XML support, but it can still be stored
in normal TEXT columns, which is better than not supporting it at all.
Closes#966.
