Rel needs a JDBC driver

Forum for discussing development of the Rel JDBC (or ODBC) driver.
Post Reply
Dave
Site Admin
Posts: 361
Joined: Sun Nov 27, 2005 7:19 pm

Rel needs a JDBC driver

Post by Dave » Sun Nov 27, 2005 8:31 pm

Rel needs a JDBC driver. If you're interested in helping to develop one, please reply to this topic.

Rene Hartmann

Post by Rene Hartmann » Sat Mar 25, 2006 12:32 pm

I am thinking about a Java interface to a D, but I doubt that a JDBC interface is very useful. After all, if you don't use SQL, it will not be really JDBC-compliant, even if you use the JDBC API (which is very SQL-oriented).

I'm thinking about a Java API for a D system, similar to other DBMS APIs (like JDBC, JDO, Hibernate ...) but designed for a D, a kind of a "standard" API for D systems (even if there is probably not enogh support in the Java community to make it a Java standard) and which could be implemented by different D systems (like Rel and Duro).

I personally prefer an interface that works without using a sublanguage, but I think both approaches (with and without using e.g. Tutorial D as a sublanguage) could be integrated into a single API.

Dave
Site Admin
Posts: 361
Joined: Sun Nov 27, 2005 7:19 pm

Post by Dave » Sat Mar 25, 2006 1:25 pm

Rene Hartmann wrote:I am thinking about a Java interface to a D, but I doubt that a JDBC interface is very useful. After all, if you don't use SQL, it will not be really JDBC-compliant, even if you use the JDBC API (which is very SQL-oriented).

I'm thinking about a Java API for a D system, similar to other DBMS APIs (like JDBC, JDO, Hibernate ...) but designed for a D, a kind of a "standard" API for D systems (even if there is probably not enogh support in the Java community to make it a Java standard) and which could be implemented by different D systems (like Rel and Duro).

I personally prefer an interface that works without using a sublanguage, but I think both approaches (with and without using e.g. Tutorial D as a sublanguage) could be integrated into a single API.
Hi Rene,

It is possible to achieve full JDBC 3 compliance without using SQL. JDBC compliance is based on implementing the methods and classes defined in the JDBC specification, without reference to any particular database sublanguage. While JDBC does indeed have an SQL focus, it is explicitly not SQL-only. See, for example, page 18 of the JDBC 3.0 specification, which states:
JDBC 3.0 Specification wrote:5. Maintain the focus on SQL

The focus of the JDBC API has always been on accessing relational data from the Java programming language. This continues to be true with the JDBC 3.0 API. The JDBC 3.0 API does not preclude interacting with other technologies, including XML, CORBA, or non-relational data, but the primary target will still be relational data and SQL.
I have a specific, pragmatic reason for wanting a JDBC interface. I want to take existing Java code that uses JDBC and relatively easily port it from SQL to Tutorial D. In most cases, this would require changing only the sublanguage text, without having to change the JDBC API calls. Some JDBC features are SQL-specific, such as specifying transaction isolation levels, SQL/Java type mappings, and ResultSet concurrency, but these vary across SQL implementations anyway. JDBC users are used to dealing with that.

At the moment, I have an MSc. student whose thesis project is to develop a JDBC driver for Rel.

However, I can see considerable value your idea of a relational API that does not rely on a database sublanguage, but I regard that as orthogonal to creating a JDBC driver.

Rene Hartmann
Posts: 1
Joined: Sat Mar 25, 2006 2:22 pm
Contact:

Post by Rene Hartmann » Sat Mar 25, 2006 3:57 pm

Dave wrote: It is possible to achieve full JDBC 3 compliance without using SQL. JDBC compliance is based on implementing the methods and classes defined in the JDBC specification, without reference to any particular database sublanguage. While JDBC does indeed have an SQL focus, it is explicitly not SQL-only. See, for example, page 18 of the JDBC 3.0 specification, which states:
JDBC 3.0 Specification wrote:5. Maintain the focus on SQL

The focus of the JDBC API has always been on accessing relational data from the Java programming language. This continues to be true with the JDBC 3.0 API. The JDBC 3.0 API does not preclude interacting with other technologies, including XML, CORBA, or non-relational data, but the primary target will still be relational data and SQL.
But the quotation above says that JDBC focuses on relational data and SQL.

And the JDBC Specification states:
JDBC 3.0 Specification wrote: 6.2 Guidelines and Requirements

The following guidelines apply to all levels of compliance:
- A JDBC API implementation must support Entry Level SQL92 plus the SQL command Drop Table (see note.)

Dave
Site Admin
Posts: 361
Joined: Sun Nov 27, 2005 7:19 pm

Post by Dave » Sat Mar 25, 2006 4:24 pm

Rene Hartmann wrote:
Dave wrote: It is possible to achieve full JDBC 3 compliance without using SQL. JDBC compliance is based on implementing the methods and classes defined in the JDBC specification, without reference to any particular database sublanguage. While JDBC does indeed have an SQL focus, it is explicitly not SQL-only. See, for example, page 18 of the JDBC 3.0 specification, which states:
JDBC 3.0 Specification wrote:5. Maintain the focus on SQL

The focus of the JDBC API has always been on accessing relational data from the Java programming language. This continues to be true with the JDBC 3.0 API. The JDBC 3.0 API does not preclude interacting with other technologies, including XML, CORBA, or non-relational data, but the primary target will still be relational data and SQL.
But the quotation above says that JDBC focuses on relational data and SQL.
It also states "...does not preclude interacting with other technologies, including XML, CORBA, or non-relational data..." :wink:

There is nothing in the JDBC 3.0 spec that specifically precludes using a non-SQL database language, nor is there anything that makes it particularly difficult to support Tutorial D. Since I have a body of existing JDBC-based code that I'd like to move from SQL to Rel, and since others no doubt have the same, a JDBC driver is justified. Furthermore, it's a well-known API, so its general acceptance is likely to smooth the way for using non-SQL D languages -- or at least more so than introducing a new API along with a new database language.
Rene Hartmann wrote: And the JDBC Specification states:
JDBC 3.0 Specification wrote: 6.2 Guidelines and Requirements

The following guidelines apply to all levels of compliance:
- A JDBC API implementation must support Entry Level SQL92 plus the SQL command Drop Table (see note.)


Yes, I've been meaning to ask the authors of the spec about that. Obviously, that (highly, highly questionable, IMO) requirement shall have to be forgone, as its non-compliance in this case is a benefit rather than a hindrance! On the other hand, I could extend the Rel grammar to (optionally, perhaps via a configuration option) support Entry Level SQL92, sans nulls.

Documentation for the Rel JDBC driver will likely state "JDBC 3.0 Compliant, except for 6.2.1 'Entry Level SQL92'", or some similar phrasing. Since various SQL implementations can't even claim compliance with that point, I don't see it as a problem.

luxspes
Posts: 9
Joined: Tue May 06, 2008 1:44 am

Re: Rel needs a JDBC driver

Post by luxspes » Tue May 06, 2008 2:30 am

What is the status on this? (The last post is from 2006)
Regards,

Dave
Site Admin
Posts: 361
Joined: Sun Nov 27, 2005 7:19 pm

Re: Rel needs a JDBC driver

Post by Dave » Tue May 06, 2008 12:47 pm

luxspes wrote:What is the status on this? (The last post is from 2006)
No further along, I'm afraid. I've been trying to convince students to do it as a dissertation project, but so far no takers.

ppurang
Posts: 2
Joined: Sat Aug 23, 2008 11:32 pm

Re: Rel needs a JDBC driver

Post by ppurang » Sat Aug 23, 2008 11:39 pm

I'd be interested in implementing the needed driver. I love the fact that Rel relies on the Java 6 platform. We could use all the new Java language additions (since 1.5), Concurrency utilities and NIO. Do you have a rough estimate of the effort needed?

Dave
Site Admin
Posts: 361
Joined: Sun Nov 27, 2005 7:19 pm

Re: Rel needs a JDBC driver

Post by Dave » Sun Aug 24, 2008 12:15 am

ppurang wrote:I'd be interested in implementing the needed driver. I love the fact that Rel relies on the Java 6 platform. We could use all the new Java language additions (since 1.5), Concurrency utilities and NIO. Do you have a rough estimate of the effort needed?
Excellent! I have no idea of the effort needed (or even how to measure it... How long is a piece of string? :)) There is a fairly minimal client-side API defined in the ca.mb.armchair.rel3.client.* package, and the facilities for communicating with a Rel server are essentially complete. The client-side API would probably need to be extended, and you can obtain metadata from the Rel Catalog via Tutorial D queries. Having not written a JDBC driver, I can only speculate on what else would be needed.

ppurang
Posts: 2
Joined: Sat Aug 23, 2008 11:32 pm

Re: Rel needs a JDBC driver

Post by ppurang » Sun Aug 24, 2008 7:09 pm

Picked up the JDBC 4.0 spec. Section 6.3 lies down the compliance guidelines. I'll let that guide my iterations.

And to set the correct expectations - I will be doing this in my spare time :)

Dave
Site Admin
Posts: 361
Joined: Sun Nov 27, 2005 7:19 pm

Re: Rel needs a JDBC driver

Post by Dave » Sun Aug 24, 2008 8:36 pm

There are no undue expectations. As little or as much as you're willing to contribute will be very much appreciated. Once you get started, let me know and I'll set you up write access to the Rel SVN repository.

Post Reply