|
From: Jacob S. <smu...@sm...> - 2007-02-14 15:45:15
|
On Wed, Feb 14, 2007 at 02:31:33PM +0000, t....@ar... wrote:
> Hello,
> I'm using PyDO 2.0 already with a remote MySQL server and it works very g=
ratifying for me.
>=20
> Now I tried to use a local SQLite database too (under Python 2.4 and pysq=
lite2), but when
> accessing the db, I get following Exception:
> Traceback =09
> ? C:\TG\ingo\src\client-1.0a1\ingo\client\model3.py 1384=09
> getSome build\bdist.win32\egg\pydo\base.py 667=09
> getDBI build\bdist.win32\egg\pydo\base.py 443=09
> getConnection build\bdist.win32\egg\pydo\dbi.py 316=09
> _connect build\bdist.win32\egg\pydo\dbi.py 228=09
> _get_driver_class build\bdist.win32\egg\pydo\dbi.py 236=09
> _import_a_class build\bdist.win32\egg\pydo\utils.py 55=09
> ? build\bdist.win32\egg\pydo\drivers\sqliteconn2.py 32=09
> KeyError: 'date'
>=20
> As far as I found out, the problem occures when registering the additional
> conversion mappings (DATE, DATETIME,...) at module init, but I don't know
> how to solve the problem.
I suppose this is a problem connected with pysqlite2 versions. I happen to
have 2.2.2 on the machine I'm sitting at right now, and here I can do this:
smulloni@bracknell ~ $ ipython
[1]:from pysqlite2 import dbapi2 as sqlite
[2]:sqlite.converters
[2] {'date': <function convert_date at 0xb7ad048c>, 'timestamp': <function
convert_timestamp at 0xb7ad04c4>}
[3]:sqlite.version
[3] '2.2.2'
=20
Could you tell me what happens when you do the above?
> PS: Will there be any further developement of PyDO? Seems not very active=
at the moment, but
> would be a great pity if it would die silently!
I'm glad someone feels that way! I'm not making a lot of changes to make to
it because in my own use I haven't needed to, but I'm still here and if
someone has new ideas and wants to dive in and work more on the project, I'm
all for it. =20
I'm also something of an enthusiast, although a somewhat befuddled one, of
SQLAlchemy, which got several things right off the bat that I didn't quite
in PyDO2:
- separation of table objects from business objects (something I always
intended, but never provided enough infrastructure to make it work)
- the sql generation entirely delegated to driver-specific engines
- modifiable query objects=20
- unit of work
=20
etc. I have the excuse that I wanted to keep more or less the same
interface as PyDO1, because I had a lot of PyDO1 code to maintain, but I
also painted myself into a corner with some early decisions. SQLAlchemy is
overall a much more sophisticated tool than PyDO and reflects much more
expertise about databases than I had to offer. It also seems a bit harder to
get cozy with, however; in PyDO a lot of thought was given to making certain
use cases, at least, extremely easy. Hence the proliferation of various
declarative wrappers for SQLAlchemy, and the fact that while there is a buzz
about it, most everyone seems to be still using SQLObject or the Django ORM.
(Maybe that will change in the next few months.)
=20
So if anyone has ideas about new directions for PyDO, I'd suggest they be
somehow informed by the example of SQLAlchemy. It might make sense for PyDO
to die a slow, natural death, or turn into yet another SA wrapper, or for
the weaknesses which stand out so sharply in comparison with SA to be
addressed with refactoring and new code while attempting to retain the
better aspects of the current api; but in any case it wouldn't make sense to
proceed pretending SA doesn't exist.
j
--=20
Jacob Smullyan
|
