On Thu, 18 Apr 2013 11:28:36 -0300 Ricardo Fabiano de Andrade <ricardofabianodeandr...@gmail.com> wrote:
RFdA> > On 9 April 2013 23:39, Vadim Zeitlin <vz-s...@zeitlins.org> wrote:
RFdA> > >
RFdA> > > First, let me explain once again what are my goals here. Basically I'd
RFdA> > > like to provide more information in the error messages from my code to
RFdA> > > allow diagnosing what exactly went wrong when using prepared
statements.
RFdA> >
RFdA>
RFdA> My needs aren't related to what went wrong during execution but what
RFdA> happened while building the query.
But isn't this mostly important when things do go wrong?
RFdA> In my case, soci's exception messages are handled externally to soci
RFdA> but I understand it can be done internally.
I'm not sure to understand this but maybe I hadn't explained my problem
well enough to begin with, so let me try to do it again. We're handling
SOCI exceptions in our own code, i.e. externally, too. But the problem is
that we don't have the information about the values of the parameters when
we catch them.
RFdA> The more important thing for me was knowing the values of the query
RFdA> parameters for each execution.
Yes, this is exactly what I want too. The difference seems to be that you
want to log them all while I just need them for the last query.
RFdA> > > Currently if you run a statement like "insert into foo(bar)
values(:bar)"
RFdA> > > and it fails with e.g. "unique constraint violation on foo.bar" error
RFdA> > > message, you have no idea which record failed to be inserted because
the
RFdA> > > actual value of ":bar" placeholder doesn't appear anywhere. The best I
RFdA> > can
RFdA> > > do is to use session::get_last_query() to give the error message of
the
RFdA> > > form
RFdA> > >
RFdA> > > unique constraint violation on foo.bar while executing
RFdA> > > "insert into foo(bar) values(:bar)"
RFdA> > >
RFdA> > > Instead I'd like to be able to say
RFdA> > >
RFdA> > > unique constraint violation on foo.bar while executing
RFdA> > > "insert into foo(bar) values(:bar)" with "bar"='baz'
RFdA> > >
RFdA> >
RFdA> > or maybe even just
RFdA> > >
RFdA> > > unique constraint violation on foo.bar while executing
RFdA> > > "insert into foo(bar) values('baz')"
RFdA> >
RFdA> The first (with separated parameters) is my preferred format and similar
RFdA> to the one I used in my implementation.
Yes, it's simple to generate and quite clear. But it can result in very
long and hence rather unreadable messages for real-life queries.
RFdA> Mixing the values of the query parameters with the literal values in the
RFdA> query may lead to confusion about the responsibility of each value.
I admit that I didn't think of this because I really don't care whether
the parameter was specified literally or as a prepared statement parameter
(if only because I always do the latter anyhow). Why is it important to
distinguish between the two cases?
RFdA> I don't think saving parameter values makes much sense.
RFdA> The query is saved because the statement is prepared with such query.
RFdA> In the case of parameters, they're just references to variables so what
RFdA> matters is their values at the time of the execution.
I wanted to save (references to?) the parameter values to avoid logging
them unconditionally but to be able to do it later if the query fails.
Again, this might be not a big deal but suppose you're working with
(potentially several) long strings, copying them to the log buffer on each
query execution could be potentially bothersome.
RFdA> First, in the current implementation (3.2.1) queries are always
RFdA> logged if log is enabled. In case of an error, the exception info
RFdA> plus the query and its parameters are useful indeed. However, there
RFdA> other kinds of situations (logical errors) out of the scope of soci.
RFdA> A user expects that soci as the chosen database interface should
RFdA> (must?) be able to lend a helping hand when these errors happen. So I
RFdA> would vote for allowing the user to choose if s/he wants to log
RFdA> never, only on errors or always.
I like the fact that currently you have access to the last query without
doing anything explicitly. I'd like to also have such access to the last
query parameters and, again, I'd like it to be enabled by default. But the
extensive logging, as in your patch, would need to be explicitly enabled,
just as you do, so I think this part is already fine.
RFdA> I took the approach of logging all the values enclosed between square
RFdA> brackets paying attention to the nulls on the indicator vector.
RFdA> Logging the size may be interesting but it's a redundant info if you
RFdA> have all the values.
Yes, but logging all values of a vector can definitely overwhelm the user
trying to understand the error message. So while your approach is fine for
the extensive logging, I don't think it's the right thing to do for the
error reporting.
Anyhow, once again, all this are details. My real problem with the current
patch is just the code duplication among the backends. IME it's not a good
idea and I'd like to centralize this code, even if this means that we don't
use backend-specific features.
Regards,
VZ
pgpfzWe0EFRq_.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
