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.
