On 18 April 2013 15:28, Ricardo Fabiano de Andrade
<ricardofabianodeandr...@gmail.com> wrote:
> On Wed, Apr 10, 2013 at 5:25 PM, Mateusz Loskot <mate...@loskot.net> wrote:
>> On 9 April 2013 23:39, Vadim Zeitlin <vz-s...@zeitlins.org> wrote:
>> >
>> > 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')"
>>
> The first (with separated parameters) is my preferred format and similar to
> the one I used in my implementation.
> Mixing the values of the query parameters with the literal values in the
> query may lead to confusion about the responsibility of each value.
In ideal world, I'd like to see SOCI reporting bugs through a
dedicated error context.
Such context would carry values, backend-sourced error message, error
status, etc.
Then, users can supply their own streams accepting it:
operator<<(std::ostream& os, soci::error_context const& ec)
This way, formatting is completely separated from actual data.
>From usability POV, error context could be carried/used by exceptions too.
>From different POV, its better to keep exceptions lightweight
(some 'schools' even suggest "no memory allocation" in exceptions).
Anyhow, it may be worth to consider it.
>> 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.
>
>
> Mateusz, what is your idea of 'meaningful context' for error reporting?
I meant context indicating what's the real problem, so we can avoid
errors aliasing leading to confusions like this one
https://github.com/SOCI/soci/issues/116
> Do you mean including extra info about the source of the error?
> (e.g. Error on prepare: bla bla bla)
Yes, I mean that too, see soci::error_context idea above, but also this:
- what SOCI operation failed (which public interface call failed)
- error may come from different levels:
-- SOCI core (i.e. SQL and placeholders parsing)
-- SOCI backend (i.e. data conversion)
-- DBMS client library used by SOCI backend (i.e. PQexec failure)
Only in the last case we have to worry about DBMS-specific
error message/status code.
Indicating which level of the infrastructure failed makes error reporting
more meaningful.
>> > 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 don't think saving parameter values makes much sense.
> The query is saved because the statement is prepared with such query.
> In the case of parameters, they're just references to variables so what
> matters is their values at the time of the execution.
Not saving, but capturing in case error is related to a query that uses values,
so we can report such values as part of error.
>> > 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?
>
> First, in the current implementation (3.2.1) queries are always logged if
> log is enabled.
Yes.
> In case of an error, the exception info plus the query and its parameters
> are useful indeed.
> However, there other kinds of situations (logical errors) out of the scope
> of soci.
Indeed, it is also what I meant by listing the levels above.
> A user expects that soci as the chosen database interface should (must?) be
> able to lend a helping hand when these errors happen.
Yes.
> So I would vote for allowing the user to choose if s/he wants to log never,
> only on errors or always.
Sure, but first there has to be errors reporting infrastructure (implemented
with possible logging in mind, as errors can be logged).
Once that is ready, we can add logging of non-error information,
as extension to errors logging.
Finally, we can make it all configurable (two logging levels should
enough: errors and info)
and optional (loging ON and OFF).
Logging levels + ON|OFF makes a few useful combinations possible.
>> 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
>
> I personally don't mind but do we (the user) really need this level of
> flexibility?
Good question. I said, ideally, so if we can achieve it easily, then why not,
but I wouldn't die-hard for that feature.
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
