[DB-SIG] Test suite update for format conversion accuracy.

Vernon D. Cole vernondcole at gmail.com
Tue May 21 00:44:53 CEST 2013

Daniele, Daniele, Daniele:

  Calm down.

It's only a __TEST__.  It doesn't restrict _anything_.

If you look in qmarkpg/tests/dbapi20.py, you will see code for Python 3
support, some of which is actually forbidden by PEP 249 -- because Python 3
did not exist when the PEP was written.  We (*) had to guess what was the
most reasonable thing to do in the spirit of the PEP, and made the changes
we thought were best to move into the Python 3 world.

(*) "We" meaning Stuart Bishop, Roger Upole, Mark Hammond, and myself,

Just because we made a test which works in Python 3, does that mean that
everyone has to switch to Python 3 tomorrow and throw away all their old
code?  Of course not.  MxODBC, for example, still does not work on Python
3.  We got ready, that is all.

Now we appear to be on the edge of a similar change cycle: SQL format
converters are becoming more common.  In the past few months you have
written one, I have written one, there is a new one going into django's
Oracle back end -- they are appearing all over the place.  Taking a closer
look is not a bad idea.  I have noticed that some of these converters have
not been careful about string literals -- and I have this funny, old
fashioned idea that the value of a literal should not change anywhere
between the source code and the data base.

Thirty years ago, when I was writing Quality Assurance software for a
living (please don't tell anyone that it was in COBOL) I learned that you
do the simple, obvious test first, then later, if you have budget, you can
mess with the corners and edges.  Every test in the dbapi20 suite is of
that simple-and-obvious variety.

The existing parameter substitution test is, roughly:

"Using the parameter style that you prefer, can I make one parameter
substitution of one simple string variable, store it in the data base, and
get it back out?"

I am proposing to change that test to:

"Using the parameter style that you prefer, can I make one parameter
substitution of one simple string variable, store it in the data base, and
get it back out, without altering the value of a nearby simple string

I really don't think that is an unreasonable test -- of any database

I am sorry that it was a program with your name attached that, I admit, I
was looking at when I decided to get off my duff and write that extra test
I have been thinking about for an age or two.  I don't really understand
Regular Expressions and was quite interested to find out the results,
because I did not know what they would be. I do not write tests for
products unless I believe in their possibilities. That's how open source
improves. We look at each other's work and learn from it, and make
suggestions -- even if that suggestion is only: "look at that, I think it
may be a bug."

Thank you, for "if isinstance(parameters, Mapping):" it is exactly the
correct answer and I had spent hours trying to find it.

You asked what ADO is. I am not sure what noun to use. Octopus comes close.
I talk to it and it talks to a hundred or so various tabular data sources.
The test suite runs against PostgreSQL, MySQL, SQL Server, and Jet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20130520/0d5b11c9/attachment.html>

More information about the DB-SIG mailing list