OpenEdge JDBC Driver Enhancement Requests (3)

Posted by abe.voelker on 05-Jan-2013 14:47

I sent three emails to openedge-enhancements@progress.com for three different enhancement requests four days ago.  I haven't heard back (no acknowledgement) so I thought I would post them here for posterity.

Statement SQL logging for OpenEdge JDBC driver

A description of the request, with as much detail as possible

Enable the debugging of SQL statements by implementing PreparedStatement#toString() and Statement#toString() to return the SQL statement that will be sent to the database.  This is a feature not explicitly defined in the JDBC API contract, but useful nonetheless and is implemented by the MySQL and Postgres JDBC drivers.

What the advantage(s) would be to you if this feature was available
It would make debugging much easier, as the ORM library I'm using (Ruby DataMapper) depends on this functionality for debug-level logging output.  This feature is particularly useful for ORM libraries as the SQL that is executed is generally assembled by the library, and not hand-coded.  So if you have a slow query it is very useful to quickly identify if the ORM is potentially mis-generating a query.

Any work-arounds to meet your needs in this area today.
There are two proxy JDBC drivers, Log4jdbc and P6Spy that could potentially shim this in, but I haven't tested either one.  The cleanest solution would be for the DataDirect driver to support this functionality without having to pollute the JDBC URI.

Standardize the URI scheme used by the OpenEdge JDBC driver

A description of the request, with as much detail as possible
Most JDBC drivers use the URI scheme
jdbc:databaseType://host:port/databaseName?param1=value1&param2=value2
However, the DataDirect JDBC driver for OpenEdge breaks this convention by moving the database name into the query string and tokenizing the query string on ;'s instead of &'s.  Also, it would be nice to get rid of the "datadirect" that's added to the JDBC URI - it doesn't add any value and just complicates parsing.

Essentially, instead of this:
jdbc:datadirect:openedge://host:port;databaseName=database;param1=value1;param2=value2
it would be nice to have this:
jdbc:openedge://host:port/databaseName?param1=value1&param2=value2

What the advantage(s) would be to you if this feature was available
Libraries that parse JDBC URIs generally expect them to follow the same pattern.  By breaking this pattern, it makes it more difficult to integrate the DataDirect JDBC driver into popular libraries.  There is no added benefit that I can readily see from the DataDirect drivers having broken out of the standard scheme.

Any work-arounds to meet your needs in this area today.
None - have to submit patch requests to libraries in order for them to be able to support the DataDirect JDBC driver for OpenEdge due to its unique URI syntax.

Make the OpenEdge JDBC driver .jar files publicly available and redistributable

A description of the request, with as much detail as possible

Instead of hiding the JDBC driver .jar files obscurely within the installation location of OpenEdge and having to instruct end-users on how to find them and move them to their Java $CLASSPATH (instructions that vary with OpenEdge version), make the .jar files publicly available and allow programmers to redistribute the .jar files with their code.

What the advantage(s) would be to you if this feature was available
It is very common for vendors of even commercial databases (MySQL, Oracle, MSSQL, etc.) to make the JDBC drivers for their databases publicly available and to allow developers to redistribute the .jar files with their code.  It makes it much easier for developers to write libraries around vendor JDBC drivers if they can package the JDBC driver the user needs instead of telling them how to go out and find it.  Making it easier to interface with a database simply makes it more likely that the database will be actually used.

For example, the Ruby ActiveRecord ORM has a JDBC adapter library that supports many different types of databases, allowing Ruby programmers to interface with them with great ease; OpenEdge cannot currently be added to this list due to the inability to redistribute the .jar files.

Any work-arounds to meet your needs in this area today.
Instead of telling my user to just "gem install jdbc-openedge" and they're ready to interface with their OpenEdge database, I have to give instructions on how to go and find the .jar files and add it to their Java $CLASSPATH.  This also complicates staging and production deploys, as it's something that has to be fiddled with on every box where code will be deployed to that needs the driver.

All Replies

Posted by Admin on 06-Jan-2013 03:00

+1 for the 3rd one... having that as a separate downloadable package makes a lot of sense.

URI standardization don't seems very important as there isn't really a standard, agree that following the same syntax used by others might make it more intuitive for the user but changing it now is not going to be easy although the URI did changed when the new type 4 drivers were introduced so it can be done again... that will make 3 different URI's depending on the version used

PreparedStatement.toString... could probably be added with very little effort and you're right that it might be used for debuging, so +1 again

Posted by abe.voelker on 06-Jan-2013 12:57

Yeah I agree the URI thing is not super important, but tokenizing the query string on ;'s is really bizarre.  If they would change just that bit it would be a big improvement, but perhaps as you said fracturing this into a third scheme isn't worth the added complexity.  Guess I should have submitted this stuff before V11 came out

This thread is closed