On 21 April 2013 13:06, Ricardo Fabiano de Andrade
wrote:
>>
>> I'd avoid ostringstream in anything where performance might be a factor.
>> Perhaps some implementations of it are fast enough but in general it is
>> rather slow and plain old ssprintf() is generally preferable.
>
>
> I agree and I u
(Apology for delay, unfortunately I expect more until mid/end of June or so :))
On 21 April 2013 12:29, Ricardo Fabiano de Andrade
wrote:
> Mateusz Loskot wrote:
>> In ideal world, I'd like to see SOCI reporting bugs through a
>> dedicated error context.
>> Such context would carry values, backe
Hi Vadim,
I'm not sure if this is still relevant, it seems that you've already
> implemented the proposed changes, so maybe it's too late,
Not, it isn't. After all your comments and suggestions I consider my pull
request a WIP.
> but just in case
> it isn't, let me make some comments about th
Hi Mateusz,
Analyzing your idea...
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&
On Fri, 19 Apr 2013 10:26:12 -0300 Ricardo Fabiano de Andrade
wrote:
RFdA> Now let's talk about a potential solution.
Hello,
I'm not sure if this is still relevant, it seems that you've already
implemented the proposed changes, so maybe it's too late, but just in case
it isn't, let me make s
Hi all,
The solution below is partially implemented in issue #138.
VZ, you already can use it with all backends but get_last_paramers is still
missing.
Also, not all planned configurations are present.
I'm going to review Mateusz comments on my previous mails before working on
further improvement
On 18 April 2013 23:43, Vadim Zeitlin wrote:
> On Thu, 18 Apr 2013 11:28:36 -0300 Ricardo Fabiano de Andrade
> wrote:
>
> RFdA> > On 9 April 2013 23:39, Vadim Zeitlin wrote:
> RFdA> > >
> RFdA> > > First, let me explain once again what are my goals here. Basically
> I'd
> RFdA> > > like to pro
On 18 April 2013 15:28, Ricardo Fabiano de Andrade
wrote:
> On Wed, Apr 10, 2013 at 5:25 PM, Mateusz Loskot wrote:
>> On 9 April 2013 23:39, Vadim Zeitlin wrote:
>> >
>> > Currently if you run a statement like "insert into foo(bar)
>> > values(:bar)"
>> > and it fails with e.g. "unique constrain
Hi Vadim,
Let me clarify some of my comments.
> RFdA> My needs aren't related to what went wrong during execution but what
> RFdA> happened while building the query.
>
> VZ>But isn't this mostly important when things do go wrong?
> I meant that my goal was keeping track of parameter values of s
On Thu, 18 Apr 2013 11:28:36 -0300 Ricardo Fabiano de Andrade
wrote:
RFdA> > On 9 April 2013 23:39, Vadim Zeitlin 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
RF
Hi all,
As some you already know I was forced to implement an improved log support
for my own needs.
The quick solution generally isn't the best one and I understand this
applies to my implementation.
However, I'm willing to fix that so I would like to make some comments on
the last discussion on
On 9 April 2013 23:39, Vadim Zeitlin 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 statem
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 mor
13 matches
Mail list logo
