From: Warren Young
Date: July 16 2007 1:35pm
Subject: Re: Weird parsing of templated query
List-Archive: http://lists.mysql.com/plusplus/6809
Message-Id: <469B7429.2080302@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.