Hello, I'd like to return to the following problem: currently, if an SQL query fails, you often have no idea why exactly did it fail because you don't have the values of its parameters. A typical example we have to deal with is that the process importing some data files into the database stops with an error like this:
database exception: violation of PRIMARY or UNIQUE KEY constraint
"PK_FOO" on table "FOO" while executing "insert into foo(a, b, c)
values(:a, :b, :c)"
This is singularly unhelpful because what the user really needs to know is
for what values of "a", "b" and "c" this violation happened as this would
allow to immediately locate the duplicate value(s) in the input. But SOCI
doesn't provide this information and without it finding the problem is very
difficult.
We've talked about this in the past and there is Ricardo's patch at
https://github.com/SOCI/soci/pull/138 from almost 2 years (!) ago as well
as my own attempt at https://github.com/SOCI/soci/issues/245 from exactly a
year ago. In spite of the date, it's really not a joke, we've been
bikeshedding this for literally years without anything to show for it so
far.
So I'd finally like to really do something about this problem. Notice that
I'm not speaking about the general purpose logging, this could be nice (or
not: all RDBMSs except, perhaps, SQLite, provide their own logging
facilities, so it's not even that obvious that SOCI needs to do it too),
but is not critical for me and so I just want to solve the problem with
insufficiently detailed error messages described in the beginning of this
message. My proposed solution is at https://github.com/SOCI/soci/pull/302
and, as you can see at https://github.com/SOCI/soci/pull/302/files?w=1 (the
"w=1" part is important to hide indentation-only changes in statement.cpp
which just distract from the point), it is really very simple:
1. Add get_name() and dump_value() to use_type_base to allow showing the
parameter values in the error messages.
2. Allow associating extra context with soci_error, which is then appended
to the error message specified in its ctor to build the full error
returned by what().
3. Wrap all interesting statement methods in try/catch which rethrow the
soci_error generated by the lower level code after recording the
information about the query and its parameters in it.
This patch is definitely incomplete, all of the items above could, and
should, be extended, e.g. (1) should be generalized to vector and
object-valued parameters, but I think it's a good start because:
- It already solves a real problem in practice.
- It is simple and doesn't introduce any code duplication.
- It has absolutely no overhead at run-time when no exceptions happen.
To return to the motivating example, the new error message would now be
(and notice that it won't be necessary to manually append get_last_query()
to it, as we do now):
database exception: violation of PRIMARY or UNIQUE KEY constraint
"PK_FOO" on table "FOO" while executing "insert into foo(a, b, c)
values(:a, :b, :c)" with a="bar", b=123, c="baz".
which is much better.
So I'd like to merge this a.s.a.p., please let me know if anybody has any
objections to this.
TIA!
VZ
pgpzh0SOKKJLw.pgp
Description: PGP signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ soci-users mailing list soci-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-users
