The Rel Forum

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

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.

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.

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.)

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..."

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.

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

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.

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?

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.

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

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.