[DB-SIG] Test Suite?
mike_mp at zzzcomputing.com
Wed Oct 28 18:32:16 CET 2009
Chris Clark wrote:
> So in summary I'd suggest
I've checked out this test suite, and it's great.
One thing that I'd like to see in any suite, which I didn't see here, is a
comprehensive exercising of unicode/encoding behavior. Python 3 will of
course make this whole issue easier as there are fewer choices of
behavior, but in the meantime this is always the area in which we
(sqlalchemy) must adjust for a wide variety of behavioral quirks. Even
though the spec says nothing about this, so perhaps is out of scope
entirely, it would at least be nice to ensure that a DBAPI is consistent
with itself in terms of its established encoding behavior:
1. Does the DBAPI accept Python unicode objects as the values within the
"parameters" collection passed to the execute() and executemany() methods
? Or must these be str() objects in all cases, or if they contain
characters that are not ASCII compatible ?
2. If yes to #1, does the DBAPI utilize the database's or the connection's
established encoding parameters when passing data to the database ? Or if
no, are properly encoded values passed through without issue if their
encoding is compatible with that of the underlying database ? Does the
usage of setinputsizes() have any impact on the situation ?
3. Do the tuples returned by the cursor.fetchXXX() methods represent
string values as Python unicode objects ? Or are they Python unicode
only in the case of result set values that were explicitly cast into
certain types on the database side (i.e. NVARCHAR), or to any character
type (VARCHAR, CHAR), or just for all string-like objects across the board
(e.g. pysqlite) ? Or are strings returned as str() objects that are
4. Does the DBAPI accept Python unicode objects as the value of the
"operation" parameter passed to the execute() and executemany() methods
(i.e. the actual statement) ? Or must these be str() objects ?
5. If yes to #4, are unicode objects which contain non-ASCII compatible
characters accepted, provided they are compatible with the database's
encoding ? This is to support table and column names that contain
non-ASCII characters, for example. Or if no, are encoded strings
accepted which contain non-ASCII characters ?
In SQLAlchemy we have flags implemented at the class level of each dialect
which specify what we've observed the behavior of the underlying wrapped
DBAPI to be. The DBAPI test suite could provide similar flags, such that
DBAPI authors can subclass the test suite class, provide the choices their
DBAPI makes as to how to represent non-ASCII data and Python strings, and
the test suite can then exercise consistency against these settings.
At the very least this would compel DBAPI authors to consider what
encoding behavior they'd like to have at both the parameter and statement
level, and to implement it consistently. These days most new DBAPIs seem
to be going the "all unicode everywhere" route, which is a good thing and
is likely due to the coming of Python 3. The case is not as consistent
for older DBAPIs, however.
> If you could report any findings here I would appreciate it! If we can
> all agree on which test to use we can be in the same state as Java with
> a definitive test suite.
> Vernon Cole wrote:
>> There is such a test, written by Stuart Bishop. I was supposed to have
>> contributed some Python 3000 patches to it, but got sidetracked. I
>> will repent shortly. In the meantime, if you are using a version 2x
>> Python you do not want my changes anyway...
>> Main branch is lp:dbapi-compliance
>> Vernon Cole
>> On Wed, Oct 28, 2009 at 2:28 AM, Julian Scheid
>> <julians37 at googlemail.com <mailto:julians37 at googlemail.com>> wrote:
>> is there a test suite I can run to test conformance of a driver
>> implementation to the DB-API 2.0 spec?
>> JDBC, for example, has this:
>> Thank you
>> DB-SIG maillist - DB-SIG at python.org <mailto:DB-SIG at python.org>
>> DB-SIG maillist - DB-SIG at python.org
> DB-SIG maillist - DB-SIG at python.org
More information about the DB-SIG