Re: Barrage of PyDO Questions and Ideas

On Thu, 2004-01-29 at 17:55, Hy Ginsberg wrote:

> 1. Both sapdbapi and DCOracle2 are based on the Python DB API 2.0
> specification, and as such, have a lot in common.  Also, there are
> other database interfaces based on that specification, which it might
> be useful to be able to easily incorporate into the PyDO framework. 
> And so I have worked up a prototype of a "PyDBAPI20" class that the
> PyDOsapdb and PyDOoracle classes can inherit from, overriding anything
> that might be non-standard.  This makes the SAPDB and Oracle specific
> code much shorter and simpler.  I would be happy to share if this
> approach interests you.

Refactoring the drivers along those lines might be much cleaner.  I
definitely would vote for consolidating the drivers and the caching
code. 

> 2. I naively took the table class definitions I had generated for use
> under SAPDB, created similar tables in Oracle, and tried to access
> them.  It seems that the oracleconn code expects the type descriptions
> in the class to be uppercase, whereas the sapdbconn code expects them
> to be lowercase.  I suspect that this is an artifact of different
> representations of these types in the SAPDB and Oracle system tables,
> and that the respective genscript modules simply write whatever they
> found for the data type right into the class definition.  This
> unfortunately implies that the class definition files are
> database-specific, and only work with the database type for which they
> were originally built.  I need them to work across databases, and will
> take a clumsy stab at it on my own.  But perhaps I can drum up some
> interest: wouldn't it be cool if there was a PyDO standard set of
> datatype descriptions, and if each of the genscript modules coerced
> whatever its particular database returned into the standard
> representation?  

First off, I think that you should be aware that eventually PyDO.PyDO2
will replace PyDO, so hacking on it is probably a better idea than on
the old PyDO.  (If it does replace it, it may do so with a slightly
different package name -- perhaps skunk.pydo -- so as to coexist with
old PyDO code and sidestep the very few backwards incompatibility
issues).

There are a couple of approaches possible here.  One would be to
normalize case in the PyDO drivers.  It should always be possible to
retrieve the underlying originally-cased field names, in case you are
mixing PyDO-generated SQL with your own SQL.

Also, we could hack the PyDO2 metaclass to delegate to another model for
its class-level table-descriptive information; that model could handle
case conversions, or other differences that arise in porting schemas
between dbmses (sequences rather than auto-increment, for instance). 
This would mean that the table would need to be able to query its driver
to find out what type it is at class construction time.  (For case
alone, the driver could handle the conversion, with less coupling
between the class and the driver, but I don't off-hand see a way of
doing that with sequenced/autoincrement.)

> 3. There are some SAPDB changes that you took from me some time back
> which, in the course of putting the miles on this stuff, turn out to
> be less than perfect (I'm going easy on myself here...).  Essentially:
> The "NOW()" function is not documented and I vaguely remember running
> into places where it didn't work -- it might have been inside
> triggers, which wouldn't matter to PyDO, but a better way to get the
> current time, documented and always works, is simply the keyword
> TIMESTAMP.  And the clever use of the lastrowid cursor property was a
> valiant effort, but there are times when sapdb drops the ball and
> simply doesn't set it -- turns out to be unusable (if you want it to
> reliably work).  I had to switch to using explicit sequences instead
> of autoincrement (serial) columns, and it would probably be better to
> remove the pretension of support for the feature.  Sorry about
> those...

I can't comment personally on sapdb -- any other sapdb users listening
in?

> 4. Python 2.3 comes complete with a "datetime" module; it seems
> logical to replace the dependence on the Egenix mx.DateTime package
> with the standard Python module.  Any plans to do so?

This issue is to some extent a bit down- or upstream of PyDO, I think. 
A bunch of drivers -- at least mysql-python and pypgsql -- use egenix
datetime natively.  We could provide adapter code to translate between
mx and datetime, or make the drivers configurable to do so.  Also, we
have to decide whether the next version of PyDO (and skunkweb) should
continue to support Python 2.2.  Since I continue to have segfaults with
Python 2.3.3, I'm beginning to think we shouldn't give up entirely on
2.2 yet :(.
 
> Let me know what you think about this stuff and I will put together an
> appropriate set of updated source files that you can use or discard,
> as you see fit.

That would be super!

js


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn