Jython support in sqlpython

[Jim Baker]

I'm one of the Jython committers. We have our own very limited db
shell, dbexts.py (http://fisheye3.atlassian.com/browse/jython/trunk/
jython/Lib/dbexts.py?r=HEAD), which sort of works but has not been
maintained for 9 years. It's also not really the sort of thing we want
to be doing in Jython core.

In looking around at various SQL shells for Python, it would seem that
sqlpython could be a great fit for Jython. Much of our recent focus on
Jython dev up until now has been on server apps, but with our
forthcoming 2.5.2 release of finally adding tab completion to the out-
of-the-box experience with Jython. This will work through the standard
readline/rlcompleter modules (but going against JLine instead of GNU
Readline).

I would see some obvious advantages for sqlpython support - you could
get "free" support through JDBC of ~200 databases out there, including
ODBC. Our zxJDBC implementation of the Python DB API 2 helps there,
and dbexts could be readily recycled by sqlpython/Gerald to add
support for schema metadata, etc. (It looks like decent code, with
some unit testing.)

Any thoughts?

- Jim

[Catherine Devlin]

Hi, Jim!  First off, sorry that I didn't notice your message in the sqlpython group approval queue.

I had no idea there was a db shell that comes with Jython... is that an expected tool in Java-land?

Wow!  I'm really flattered!  A bunch of thoughts.

- at the moment, sqlpython is at an icky not-so-workable in-between state; I think it will be ready for prime time again sometime in September.

- I doubt sqlpython is 2.5 compatible right now.  That probably wouldn't be hard to fix, though.

- AFAIK, pyparsing works with Jython, and pyparsing is the rock cmd2/sqlpython are built on.  There's some horribly ugly and slow code in there, though (on my side), and I'd love to get around to rewriting it for beauty and performance - I'd like to experiment with CodeTalker as a parser.  Though I'm open to suggestions...

- in general, sqlpython has been written ambitiously/experimentally - always stretching to get something cool in there, rather than focusing on stability and reliability.  I'd like to "retrofit" some better stability into that... but again, that would be future work.  (cmd2 is not quite so bad.)
 
Basically, I'd love to go for it, but there's a lot of code quality work (which really needs to be done anyway).  How much patience have you got?  :)

--
- Catherine

[Jim Baker]

First, let me say that I really appreciate the reaction to my email, at the very least if it can help stimulate some thinking on how to improve this project, that's a good thing.

On Fri, Aug 20, 2010 at 8:54 AM, Catherine Devlin <catherin...@gmail.com> wrote:

Hi, Jim!  First off, sorry that I didn't notice your message in the sqlpython group approval queue.

I had no idea there was a db shell that comes with Jython... is that an expected tool in Java-land?

I think it was a demo of our bridge from JDBC to Python DB API. I personally was surprised it was in there, having never heard of it until this bug report. But the capability is certainly useful.

 

...

Wow!  I'm really flattered!  A bunch of thoughts.

- at the moment, sqlpython is at an icky not-so-workable in-between state; I think it will be ready for prime time again sometime in September.

That timing is fine, see my note at the end. We just want to put this on a roadmap, so this capability doesn't get lost.

 

- I doubt sqlpython is 2.5 compatible right now.  That probably wouldn't be hard to fix, though.

- AFAIK, pyparsing works with Jython, and pyparsing is the rock cmd2/sqlpython are built on.  There's some horribly ugly and slow code in there, though (on my side), and I'd love to get around to rewriting it for beauty and performance - I'd like to experiment with CodeTalker as a parser.  Though I'm open to suggestions...

I was not familiar with pyparsing until now, but its author has tested it with Jython (and IronPython), and it's compatible. I don't believe CodeTalker is focusing on compatibility, but on performance using C. Maybe there's a pure Python equiv built in or someone could write a Java backend. Umm, that's not going to be me, got enough on the plate you see ;)

 

- in general, sqlpython has been written ambitiously/experimentally - always stretching to get something cool in there, rather than focusing on stability and reliability.  I'd like to "retrofit" some better stability into that... but again, that would be future work.  (cmd2 is not quite so bad.)
 

 

shells tend to evolve that way, but it's good to invest in the stability too. One of the least fun parts of multiple database backend testing is the setup of said databases to prove that. It would seem this is something that sqlpython would need to support for itself, and perhaps can make easier for other projects too.

The other thing I would suggest is to ensure unicode works properly. Jython's db backend does get that part right, we actually worked with Django on this about 2.5 years ago through a number of tickets to clean up their usage and our support. I believe this was also helpful for SqlAlchemy later. I believe this is a still an issue with some of the other db backends out there.

Basically, I'd love to go for it, but there's a lot of code quality work (which really needs to be done anyway).  How much patience have you got?  :)

Jython dev is pretty patient, I would have to say. You just don't do this sort of thing, and expect anything else. So it would be awesome if sqlpython dev can make these improvements to its codebase and look at adding our zxJDBC backend (for that ~200 database support!). We can certainly help you on any problems that may come up.

- Jim