List:MySQL++« Previous MessageNext Message »
From:Steven Van Ingelgem Date:July 16 2007 2:05pm
Subject:Re: Weird parsing of templated query
View as plain text  
Thanks for your answer, but it's no good ;-).


You see, I'm working with a
network framework which is strictly defined as "no overloads
possible"... (because
of multiple language support).
So then I would need to use fetch1() fetch2() if you are correct.
That is clearly insane because how many would you need to provide, 10, 20???

I liked the simplicity of the previous version: parse(), define parameters,
store(). Now it's parse(), store(<parameters>). With the major drawback you
have to know it.

I am in fact looking a little at prepared statements. Moreover because the
framework can be used on multiple databases as well, so for example on an
Oracle it's using the internal prepared statements for Oracle. But for the
end user it's still the
same API. Only they need to instantiate a different object.

It would be ok however if I could pass a vector<SQLString>. But not entirely
happy with it... Because I would like to use also named templated values.
And what if I want to bind parameters not in a logical order?

Another case for example: I am constructing an ALTER statement. So i'm
pushing %0q into the sql string and the real values in a vector. Then after
the alter-string is generated, I loop over this vector and do a bind with
each parameter (say: def[ <int> ] = <value>).

I have absolutely NO idea how many alters will come in, I just loop over
them and combine them...

So what you say is that I should do something like switch( vector<>.size() )
{ case 1: execute(vector[0]); case 2: execute(vector[0], vector[1]); ...).
Again ... This is insane ;).


The main problem is that mysql++ the way it is now is good for when you KNOW
what is coming in. But for dynamically generated queries it's just :(.
Maybe you could add some feature for MySQL 5+ (prepared statements are
possible from then right?) where you could build a prepared statement?


Greetz,
Steven





On 7/16/07, Warren Young <mysqlpp@stripped> wrote:
>
> Steven Van Ingelgem wrote:
> >
> > People can say like:
> >
> > DatabasePtr->preparestatement( "SELECT * FROM %0 WHERE %1=%2q;" );
> > (I don't know how many parameters there are here!, this is all client
> > sided).
> > +--> this calls query << "passed query"; query.parse();
> >
> > PrepSttPtr->bindParam( <position|name>, value );
> > +--> this calls query.def[ <position|name> ] = value;
> >
> > PrepSttPtr->fetch()/runQuery()
> > +--> this calls store/execute
>
> If the queries are known at compile time, I would say you have designed
> the wrong interface.  You should just provide an equivalent of the
> current MySQL++ interface.  Your example of three parameters would be
> followed by a call like
>
>         PrepSttPtr->fetch(a, b, c);
>
> If the queries come as input to the program after it's compiled, I don't
> see the need for template queries at all.  There should be no need to
> build the query in two parts in this case.
>
> > They can even re-use the preparedstatement, only re-binding the
> > changed parameters (for example a big update).
>
> Template queries are not "prepared statements".  That refers to a
> specific MySQL server feature in which the query is pre-parsed on the
> server side, so that subsequent calls save some execution time.
> MySQL++'s template queries do not make use of this feature, and enjoy no
> speed advantage.
>
> I point this out in case you are trying to justify the use of template
> queries with this misconception in mind.
>
> > This worked untill lately I upgraded to v 232. In this version I don't
> find
> > a way to (without a hack) make it work again.
>
> Well, it was a hack to begin with.
>
> > I fixed it by adding in query.cpp at the very last line of the proc()
> > function: "p.processing_ = false;"
> >
> > processing_ is defined as "has been processed"...
>
> No, that's not how it is defined.  When true, this flag means the
> SQLQueryParams object is being processed at that moment.  Processing
> isn't complete until after proc()'s caller exits, in order to prevent an
> infinite recursion loop.  The only reason this seems to work is because
> in your particular use, there are two SQLQueryParams objects: Query::def
> and the temporary created in some versions of execute() and friends.
> You're only marking one of them as finished processing, so it happens to
> work.
>
> I suspect you'll still hit the infinite call loop in some uses with a
> single parameter with this change, though I can't prove it right now.
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe:
> http://lists.mysql.com/plusplus?unsub=1
>
>

Thread
Weird parsing of templated querySteven Van Ingelgem14 Jul
  • Re: Weird parsing of templated queryAndrew Sayers14 Jul
  • Re: Weird parsing of templated queryWarren Young16 Jul
    • Re: Weird parsing of templated querySteven Van Ingelgem16 Jul
      • Re: Weird parsing of templated queryWarren Young16 Jul
        • Re: Weird parsing of templated querySteven Van Ingelgem16 Jul
          • Re: Weird parsing of templated queryWarren Young16 Jul
            • Re: Weird parsing of templated querySteven Van Ingelgem16 Jul
              • Re: Weird parsing of templated queryWarren Young16 Jul
                • Re: Weird parsing of templated querySteven Van Ingelgem16 Jul
Re: Weird parsing of templated queryroberto previdi16 Jul
  • Re: Weird parsing of templated queryWarren Young16 Jul
Re: Weird parsing of templated queryroberto previdi16 Jul