[storm] Python 3

[James Henstridge]

On Thu, Jan 8, 2009 at 12:21 AM, Vernon Cole <vernondcole at gmail.com> wrote:
> On the Windows side of things, adodbapi should be ready for Python 3
> in a few weeks, so a version 3 capable adapter could soon be
> available. (Wouldn't it be funny if Windows storm had a feature before
> Linux?)

That's great news for adodbapi.  Note that we do have the sqlite
driver to allow some testing on Linux though (that said, PostgreSQL
support is pretty important to us).

> The present storm branch which uses adodbapi is targeted at
> Microsoft SQL, but that unnaturally limits the interface.  adodbapi
> can talk to many databases, including MySQL. I have not actually
> tested it with PostgreSQL, but it is supposed do that, too.

The database specific code in Storm is about half to manage
differences in the Python drivers (e.g. parameter bindings) and half
to manage differences in the databases (e.g. discovering primary key
values for auto increment columns).

Unless adodbapi itself can paper over the differences between
databases, you'll still need database specific code.

>  One of my goals in life has been to get storm talking to MSSQL --
> that is why I have taken on the maintenance of adodbapi.  But it would
> be easier to do a storm<->adodbapi<->MySQL backend than a
> storm<->adodbapi<->MSSQL backend, and it would be a reasonable
> stepping stone in getting an MSSQL backend running. That way the
> actual operation of the api can be debugged separately from the
> idiosyncrasies of Microsoft's dialect of SQL.

Right.  I'd imagine a lot of the code in the existing backends could
be reused (perhaps via subclassing?).


>  [Also, it would make multi-database access more installation
> friendly. I have a (non-storm) script in production which talks to SQL
> server or MySQL or SQLite and AS400 SQL simultaneously. (It accesses a
> postal-code database on the PC network and a customer database on the
> mainframe.)  I can do it with only two imports -- the built-in one for
> SQLite and adodbapi for all the rest.]
>
> My question is, which would be better:
>
> 1) Create multiple database adapters requiring multiple schemes, so
> that I use a different URL depending on whether I am accessing (for
> example) MySQL using ado, or MySQL using MySQLdb.
>    database = create_database("mysql://username:password@hostname:port/database_name")
> vs.
>    database = create_database("adomysql://username:password@hostname:port/database_name")

It would be nice if the first form could work.  I'm not sure of the
best way to structure that though.


> 2) Let the backend itself itself probe for the modules it might be able to use:
>   try:
>       import MySQLdb as db
>       import MySQLdb.converter
>   except ImportError:
>       try:
>         import adodbapi as db
>      except ImportError:
>         db = dummy
>   db.connect('connection_string')
>
> My feeling is that option 2 is the more pythonic way to go.
> Would such code be accepted in the trunk?

Well, there is a bit more to the backend than just the connect statement.

If you're up for a bit of throw-away prototyping, one thing you could
try would be a straight port of the mysql backend to your database
adapter and get all the tests passing on it.  The changes you make
should give an idea of how much code makes sense to share.


James.