List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:April 1 2007 11:15pm
Subject:Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())
View as plain text  
Michael Hanselmann wrote:
> 
> On Tue, Mar 27, 2007 at 10:01:03PM -0600, Warren Young wrote:
>> I just changed examples/tquery.cpp to make it match the code you posted 
>> as closely as possible, and I can't duplicate it.
> 
> Yes, it works. However, I use a somewhat different structure as you see
> below.

I don't see any easy way to work around this short of rolling back the 
null byte fixes in 2.2.0, which are far more important.

Frankly, your use of the library in this way is arguably abusive. 
Query::def is meant to contain defaults that rarely change over multiple 
queries, as you see in resetdb.  If there is only one template 
parameter, then it must be changing with every query, or else there 
would be no point to using template queries at all.  There are no 
"defaults" in this use of MySQL++.

I recommend that you just change your code to use the single-parameter 
form of Query::use() instead of the void version, rather than use named 
template query parameters.  I realize that named parameters are nice, in 
that they are self-documenting, but when there is only one parameter, 
this isn't greatly valuable.

The only way you can get me to relent would be to provide a patch that 
supported your use while not breaking anything else, and I might reject 
it for complexity reasons anyway.  I spent some time looking for a way 
to do this, but this is one of the most complex areas of MySQL++.  It 
seems to me that if you did find a way to fix this, you'd make the code 
more brittle, by adding more code paths through an already tangled area 
of MySQL++.  Notice how much commentary I felt was necessary in 
functions like Query::use(SQLString&), to avoid confusion on related 
matters.  I don't want to make it still more complex without a really 
good reason.  Since there is a viable alternative which IMHO is actually 
better, I lack that good reason.

Ultimately, the problem is that we can't break the ABI right now.  We 
need to do that in order to disentangle the template query mechanism 
from the regular uses.  That's the real fix, but we can't do that yet.

> - Setting a parameter to 0 or any other integer value directly causes a
>   segfault. Most likely this is because it's implicitly casted to char*.
>   I don't know whether this can be fixed. Checking for NULL only isn't
>   enough.

I don't think it's worth trying to fix.  Just say "0" instead.  (i.e. 
pass an explicit string instead of an integer literal.)

> Feel free to include the gdb code in exrun.

Thanks, I have, with some modifications.
Thread
Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann25 Mar
  • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young26 Mar
    • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann26 Mar
      • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young28 Mar
        • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young28 Mar
        • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann31 Mar
          • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young2 Apr
            • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann2 Apr
              • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young3 Apr
                • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann4 Apr
Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young29 Mar