FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: April 1, 2004 2:05 PM
> 
> Jmaes... we get a lot of script (Perl & PHP) problems with examples...
> it's hard to convert these examples in C tests however I 
> don't imagine a
> simple script for doing all tests we need... I remember your 
> propose of
> a script. Are you thinking something specific ?? Another idea would be
> compile some PHP/Perl tests if available... not that easy however...

The specific thing I had in mind was one general-purpose query processor 
(along the lines of tsql) for each client library.  I think it should be able 
to read its SQL from stdin, write output to stdout, and errors to stderr.  It 
should be able to handle regular and computed results, but it wouldn't deal 
with rpc or dynamic queries (unless we invent a syntax for that, which seems 
like more effort than it's worth).  

These "batch sql" processors, correctly written, would serve other purposes 
beyond simplifying and expanding our testing regimen.  They would be useful 
in their own right for batch environments (and therefore should probably 
reside in src/apps instead of src/*/unittests).  And they could serve as a 
reference model for anyone writing an application.  People frequently want 
sample code, and we don't have any really good samples.  The standard answer 
to "How do I do X in ct-lib?" would become "Look at bsql-ct".  

We could use such "batch sql" processors in the unit testing by wrapping them 
in a script that understands the PWD file and invokes them appropriately.  I 
know it's possible to tell autoconf to invoke test scripts; it's just a 
matter of figuring out how.  (Maybe these wouldn't go in the unittest 
directories at all; maybe they justify a src/test or src/app/test directory.  

For Perl and PHP, we need the same thing, more or less.  If we had a 
"bsql-dbi-sybase" Perl script that could read SQL from stdin, etc., we could 
feed it the same SQL script we feed any of the other batch processors and see 
how it reacts.  I assume we could do the same for PHP.  

I think the time has come to tackle this, because, as you observed a little 
while ago, the problems are getting more subtle.  A few years ago there were 
examples of integers losing digits in conversion or failures to interpret 
tokens in the data stream, the kinds of things that are pretty easy to spot 
and test for.  Now that the basics are under control, we need more 
comprehensive testing.  Also, if we make testing relatively easy, then folks 
who have PHP, say, installed might be more willing to do a quick 
rebuild/relink/test once in a while, just to make sure things still work.  

And I think we have the talent among the 700-some subscribers here to write 
these processors.  Several people here are quite savvy with their chosen 
language or API.  It's just a small matter of programming.  

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to 
inform and update our clients, prospects and consultants of developments 
relating to our services and products, would not like to receive further 
e-mail correspondence from the sender, please "reply" to the sender 
indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, 
NY 10105.