Hello again, I've started looking into implementing logging of the last query parameters and immediately realized that it's not going to be as simple as I thought so I'd like to ask for some advice here.
First, let me explain once again what are my goals here. Basically I'd
like to provide more information in the error messages from my code to
allow diagnosing what exactly went wrong when using prepared statements.
Currently if you run a statement like "insert into foo(bar) values(:bar)"
and it fails with e.g. "unique constraint violation on foo.bar" error
message, you have no idea which record failed to be inserted because the
actual value of ":bar" placeholder doesn't appear anywhere. The best I can
do is to use session::get_last_query() to give the error message of the
form
unique constraint violation on foo.bar while executing
"insert into foo(bar) values(:bar)"
Instead I'd like to be able to say
unique constraint violation on foo.bar while executing
"insert into foo(bar) values(:bar)" with "bar"='baz'
or maybe even just
unique constraint violation on foo.bar while executing
"insert into foo(bar) values('baz')"
Now that we understand what we'd like to do, the question is how to do it.
For consistency with the last query itself, it would seem to be logical to
save the parameters values in statement_impl itself: it already calls
session::log_query() in its ctor and it could call some log_parameters() in
its define_and_bind(). But this is where I have my first question: do you
think it could be a noticeable pessimization, from performance point of
view, to always log the input parameters here? I haven't done any profiling
yet but I have a suspicion that it could add a noticeable overhead,
considering that queries can have a lot of parameters and all of them would
need to be converted to strings (I think, see below) during each execution
of the query.
And if we need the parameter values for error reporting only, then we
could avoid this potential overhead by logging them instead only in case an
exception is indeed thrown, i.e. catch all the exceptions in
statement_impl::execute() (and also in fetch() probably?), log the values
of the parameters, and then rethrow. Do you think such approach would be
better?
Finally there is also a question of how to log the parameter values
exactly. The problem here is that use_type_base itself doesn't provide any
access to its value. Is there any better way to show parameters than
straightforwardly extending use_type_base with some as_string() virtual
method? Also, converting all the parameters to strings risks is what
worries me from performance point of view, if we do it unconditionally. It
would be nice to avoid doing this unless really necessary but to make this
possible we'd need to have a shared (i.e. ref-counted) pointer to
use_type_base but this would change the life time of use_type_base objects
and I'm not sure that it's not going to create any problems. Am I worrying
too much and should we just make these objects ref-counted or should we use
the assuredly safe convert-to-string-immediately approach?
Ah, and I lied about "finally". The really last question is about vector
use types. I don't use them myself (although I should), so I'm not sure how
should we log those. For now I was thinking about logging just the number
of elements in the vector and its first element, does anybody have any
other proposals for them?
Thanks in advance for any thoughts,
VZ
pgpJP7mkqmkcg.pgp
Description: PGP signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ soci-devel mailing list soci-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-devel
