On 9 April 2013 23:39, Vadim Zeitlin <vz-s...@zeitlins.org> wrote:
>
> 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')"
Vadim,
I like your idea. It is important do feature to be able to report errors with
meaningful context. The actual format of report is a secondary issue,
so it can be decided later.
> 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?
There is potential of performance decrease.
So, we should be careful about it, indeed.
> 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.
I doubt we can perform meaningful benchmarks in short time.
It would have to take awful lot of factors into account to draw any meaningful
conclusion. In my opinion it's easier to base on assumption that strings
bashing and formatting is a slow character by character operation.
> 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?
If I had to choose between permanent logging vs on-error logging,
I'd vote for this approach, to process values on error only.
Although, it will require us to do more coding work to consider all
exception aware places and handle the exceptions as you describe.
But this, AFAIU, will loose the feature of logging on demand.
So, perhaps we could have both and still save the performance
by controlling this behaviour conditionally with use of dedicated
configuration properties. Have you considered it?
> 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?
This is tough one and I don't have time at the moment, but I will think about it
during this weekend. Perhaps, I will be able to give a sensible response.
> 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?
Ideally, if this was configurable I think:
- by default, report containre metadata only (size, type(s))
(BTW, we may also consider {boost|std}::tuple, boost::optional).
- on demand, dump all content
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
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
