Such dialogs can be unexpected and confusing, as reconnection can happen
automatically, and not in a response to a user action.
Implement this by adding a new "reconnect" option and add is_option_on()
helper to connection_parameters to facilitate using it.
Nowadays all systems can deal with LF-only files (perhaps with some rare
exceptions, not affecting SOCI) and there is no need to force
normalization in the repository itself -- people who need it can always
enable it in their global Git config.
The latest version seems to have problems and reports
/usr/local/lib/node_modules/markdownlint-cli/markdownlint.js:52
} catch {
^
SyntaxError: Unexpected token {
when installing it, so revert to the last known working one.
Co-authored-by: Mateusz Loskot <mateusz@loskot.net>
Use fully qualified "soci::session" type name to avoid conflicts with
"session" struct declared in sys/proc.h under macOS.
This is a recurrent problem (see #605 for a previous example of it)
which should probably be solved by removing "using namespace soci" from
the test to prevent it from happening again.
Closes#832.
This wasn't done before in case of connection failure in connect(), so
PQfinish() could be called with a dangling pointer from clean_up(),
called from the dtor, later.
Just initialize conn_ in ctor to fix this.
Closes#822.
The function search_paths() was accidentally defined in the global
namespace instead of "dynamic_backends" one, as it was supposed to,
meaning that dynamic_backends::search_paths() was not defined at all and
attempts to use it resulted in link errors.
Closes#829.
At least PostgreSQL ODBC driver just returns "HY000", i.e. "General
error" in case of connection loss, which clearly can't be always mapped
to soci_error::connection_error, so we need to take into account that
get_error_category() doesn't always return the expected value, at least
with the ODBC backend.
Try to return something meaningful from get_error_category() for a few
SQLSTATE values that seem to be reasonable standard and map well to the
existing error_category enum values.
This is far from being exhaustive, but is still better than nothing and
allows "Reconnect" unit test to pass when using MS SQL ODBC driver.
This function can be used to check if the connection to the server is
still available (and then, perhaps, call reconnect(), if it isn't).
Implement it for all backends using native API (except for SQLite for
which it always returns true).
Set error category to connection_error for ORA-03113 which occurs if the
server is not running any longer, ORA-03114 which happens in case of a
network problem and also for ORA-12541 which seems similar to ORA-12162,
which was already mapped to connection_error.
This allow the manual "Reconnect" test to pass with Oracle backend.
This test is disabled by default, but can be run explicitly to check
that we can automatically recover from connection loss when using a
backend supporting this (currently only Oracle and PostgreSQL, and only
tested with the latter).
If the failover callback doesn't provide the connection string to use,
default to the originally used one instead of using empty connection
string which is almost certainly not what we want.
Note that this requires storing the original connection parameters in
postgresql_session_backend, as we don't have access to the ones stored
in the session object and it seems wrong to add backlinks from the
backend to the session object.
Closes#793.
This can't be tested automatically, as we don't really have any way to
break the connection programmatically, but we can still have a test for
this relying on breaking (and then restoring) the connection manually.
When working directly with concrete statement_backend classes, their
alloc() and clean_up() methods must be called directly, which suffers
from all the usual problems, especially in presence of exceptions.
Avoid them by using the new auto_statement class which takes care of
calling these methods in its ctor/dtor instead.
An alternative could be to make the concrete classes themselves use
RAII, but this would be more error prone (e.g. there would be a risk of
alloc() being called twice) and require many more changes, so, at least
for now, use this more lightweight solution.
No real changes.
Add another C++11-like macro (similar to SOCI_OVERRIDE) which can also
be used in C++98 code.
The main advantage is that new code can now use SOCI_NOEXCEPT instead of
the old "throw()" and it will be possible to simply replace it with
"noexcept" after dropping C++98 support.
Define SOCI_DEFAULT_CMAKE_OPTIONS once and use it in almost all builds
instead of repeating the same options many times everywhere.
For the remaining build (Valgrind) still reuse a couple of options which
it has in common with the other ones.
This is not always a good idea, as it can result in errors when building
with a newer compiler or on a new platform, even if the warning reported
are not really harmful, so don't do this by default.
This allows the suppression to still apply even if the exact library
name changes, as it recently happened in Travis CI Ubuntu Xenial build
environment (where it is 20.3.17 now instead of 20.3.12 as before).
Since a null character is added, we must use SQL_LONGVARCHAR in this
case as the effective length is too big for SQL_VARCHAR.
Close https://github.com/SOCI/soci/pull/819
This completes the changes of 60fe9f3c (Suppress -Wcast-align in ODBC
backend code under ARM, 2020-06-04), which fixed only the first
occurrence of a warning, which happened in several other places as well.
See #812.
This warning should be harmless, so just suppress it to allow building
SOCI under ARMv7hl architecture (all warnings are fatal due to the use
of -Werror).
Closes#812.
The application may enable (sometimes even inadvertently, simply due to
its use of another ODBC library which does it, e.g. pyODBC does this by
default) the use of pooled ODBC connections before trying to open a SOCI
session.
In this case, only the use of SQL_DRIVER_NOPROMPT is allowed by ODBC
driver manager and attempts to connect with any other "completion"
parameter value result in ODBC error "HY110". As the code using SOCI
may be completely oblivious to the use of pooled connections (e.g. SOCI
is used by another library in the same application and has no knowledge
whatsoever about the first library), it makes sense to try to do our
best in this situation and automatically try to fall back on connecting
with SQL_DRIVER_NOPROMPT in this case.
This commit implements this solution by adding a special check for this
case.
Note that these changes are best viewed ignoring whitespace.
Replace all the other uses of sscanf("%lld") and "%llu" with the calls
to cstring_to_integer() and cstring_to_unsigned() respectively, which
should be faster and provide better error checking.
There should be no change in behaviour.
Generalize the use of strtoll() instead of sscanf() for the conversion
to unsigned integer types too and extend the code doing it to a couple
of new simple reusable functions that can now be used in all backends.
Keep PostgreSQL idiosyncratic conversion of "f" and "t" to integers to
avoid changing the existing behaviour, even if it's not really clear
whether this is needed for all types.
Remove apparently unused conversion_use_type::convert_from_base() which
prevents this class from being used with const references.
Closes https://github.com/SOCI/soci/pull/797
Unfortunately we don't get any information about these leaks, the entire
report looks like this:
==6706==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f6473f80602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x7f646f89ba82 (/usr/lib/x86_64-linux-gnu/odbc/psqlodbca.so+0x1ba82)
Indirect leak of 25 byte(s) in 1 object(s) allocated from:
#0 0x7f6473f80602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x7f646f89ba9a (/usr/lib/x86_64-linux-gnu/odbc/psqlodbca.so+0x1ba9a)
SUMMARY: AddressSanitizer: 49 byte(s) leaked in 2 allocation(s).
So we have no choice but to suppress all leaks from psqlodbca.so to let
the tests to pass on Travis CI.
Unfortunately we don't get any real information about these leaks, the
entire report is
==10667==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 176 byte(s) in 1 object(s) allocated from:
#0 0x7ff24b649602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x7ff23f0ef551 (<unknown module>)
Indirect leak of 744 byte(s) in 3 object(s) allocated from:
#0 0x7ff24b649602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x7ff23f0ef551 (<unknown module>)
Indirect leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7ff24b649602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x7ff23f456d89 (<unknown module>)
So we can only disable leaks coming from libasan.so to suppress them
which, of course, risks hiding any other leaks too. The only way to
check for them is to check that the count of suppressions in libasan.so
doesn't increase beyond 5.
Vadim Zeitlin