Road to JDBC API compliance

[jorsol]

JDBC compliance requires full support for the JDBC API and full support for SQL 92 Entry Level. It is expected that JDBC compliant drivers will be available for all the major commercial databases.

PostgreSQL supports SQL 92 Entry Level (and much more), but the comment of jdbcCompliant() is misleading:

For PostgreSQL, this is not yet possible, as we are not SQL92 compliant (yet).

This comment can be tracked to a commit made in 1998, almost 20 years ago:

pgjdbc/postgresql/Driver.java

Lines 174 to 175 in 121396c

	* <p>For PostgreSQL, this is not yet possible, as we are not SQL92
	* compliant (yet).

So I will keep this issue open to track the JDBC compliance and change jdbcCompliant() once is confirmed that this checklist is complete.

Claim JDBC compliance can be tricky since the JavaDocs states:

A driver may only report true here if it passes the JDBC compliance tests

But the reality is that not many have access to the TCK suite (who wants to pay oracle?), so we just stick to the JDBC specification.

I will add a long checklist here, any comments and discussion is welcome, it will be divided in 4 parts, for each JDBC specification supported (4.0, 4.1, 4.2, 4.3), the specification is mostly incremental, so practically all of the points are valid in subsequent versions, so they are not repeated again.
Items with no check, don't necessary means it's not supported, it can be supported but not checked/verified, leave a comment if you verify that it's implemented.

JDBC 4.0 API Compliance (Java 6)

• Support auto loading of the drivers java.sql.Driver implementation
• Support a ResultSet type of TYPE_FORWARD_ONLY
• Support a ResultSet concurrency of CONCUR_READ_ONLY
• Support batch updates
• Fully implement the following interfaces:
  • java.sql.Driver
  • java.sql.DatabaseMetaData
  • java.sql.ParameterMetaData
  • java.sql.ResultSetMetaData
  • java.sql.Wrapper
  • javax.sql.DataSource

TODO

JDBC 4.1 API Compliance (Java 7)

TODO

JDBC 4.2 API Compliance (Java 8)

TODO

[davecramer]

FWIW, at one time it did pass the TCK. The suite is such that you can leave certain things out, and write your own adapters to make it work. I don't really think compliance is a worthy goal. As you point out there is no way to prove it

[jorsol]

I don't really think compliance is a worthy goal.

Well, I don't know about the TCK, but the spec have a chapter about compliance and that's the closest we can get. That is what standards and specification are, a set of guidelines to follow and when someone uses a technology, they can expect that will work like others that follow the standard, based on this many technologies builds on top of JDBC and can use similar features with different databases.

But if you really think compliance is not a worthy goal, we should remove that from the website:

Our goal is nothing short of full compliance, but we're not there yet.

Since you are one of the maintainers, I will close this issue unless someone think compliance is a worthy goal.

[davecramer]

I think it's OK to leave it open. My comments may have been a bit hasty, however having gone through the process of running the TCK on the driver quite a few years ago, had I not been paid to do it, I certainly wouldn't have undertaken the work. Nobody really cared at least nobody said they did.

[jorsol]

Nobody really cared at least nobody said they did.

The funny thing is that maybe you're right, I try to create a discussion and comments around this and of the more than 65 watchers, only one reply.

[brettwooldridge]

@jorsol Issue #855 belongs on this list as well. I'll try to work on this in the next few weeks.

[jorsol]

@brettwooldridge yes, I'm pursuing this in a different fork, my focus will be try to have the most JDBC compliant driver posible.

[maroony]

@davecramer, @brettwooldridge, @jorsol SquirreL users have to stick on version 42.2.8 because of not implementing java.sql.DatabaseMetaData. Is there a chance that this will ever be happen?

[davecramer]

@maroony It would have a much better chance if an actual issue describing the problem was created. However it appears that #1723 needs to be backpatched.

[maroony]

@davecramer Thanks for your quick reply. I was searching for an issue and found this one. I'm not really into the details regarding the squirrel-sql issue. Can I do something else or does backpatching #1723 fixing this?

[davecramer]

@maroony backpatching should fix it. But ya know had squirrel actually raised an issue this would have been addressed quite some time ago. :)

[davecramer]

@maroony I looked at this and I don't see any issues in the driver