paulruizendaal wrote:

>Jim,
>
>
>
>
>>There would be, over time, three implementations of the interface.
>>One, inside the engine, would be used in modules to replace the
>>existing pre-processed modules (met, dfw, ini, etc). Once
>>complete, the engine could be build without preprocessor.
>>
>>
>
>Hmmm... This means that the engine will use SQL strings inside. These
>must be compiled and compiling SQL is more expensive than compiling
>BLR. Hence, the caching of "compiled requests" (or better, "prepared
>statements" in the new model) becomes even more important. As I noted
>in a previous post, I think that this caching code around queries
>obfuscates code flow in the current engine code.
>
>

Sorry about the delay. Our idiot phone company cut our T1 for the
second time in 72 hours, with an average of 6 hours to respond. Grrrr.

Yes, the engine will use SQL strings in side. Initially it means three
levels of processing -- JDBC, DSQL, then BLR. Without compiled
statement caching it would be a disaster. But with cached DSQL
statements, it would probably be faster than the existing code, a tiny
fraction the size, and a great deal simpler. Other than that, the idea
doesn't have much going for it, other than eleminating a two step build
process and a circular dependency.

The Jdbc layer really doesn't introduce enough overhead to worry about.
A couple years down the pike, there would be an opportunity there, but
there are many better places to put effort in making the system go faster.

>What are your thoughts? Keep caching code around actual queries, as
>now? Put some chaching mechanism in the PreparedStatement class? Rely
>on a db-wide SQL string cache, as you proposed in an earlier post?
>Something different still?
>
>
>

System wide SQL statement cache. Ann is arguing for normallized SQL
statements with single spaces in place of arbitrary white space and
uniform capitialization. It's hard to argue against what is not more
than an hour of work, but I don't believe it will buy much but domestic
peace.