On 18 April 2013 23:43, Vadim Zeitlin <vz-s...@zeitlins.org> wrote: > 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?
Exactly, AFAIU, what went wrong is a syndrome of what happened while building query. > 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. The lack of information makes me think an error context to carry all of it is needed. > 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. I haven't reviewed the patch in details, so I take Vadim's words here. Given the current code, I actually think there is code duplication already (i.e. bits used for data values conversions) across backends. So, I'd prefer to not to see more :-) > 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. In big picture, we definitely need some soci/common/ module. >From single-backend author POV, there is no such thing as code duplication and (re)using such common library of utilities is more a hassle than simply writing code directly, but from the whole SOCI perspective, common library would make things easier (testing included). 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
