db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Wilder <0505...@acadiau.ca>
Subject EG meeting feedback - July 27, 2005
Date Wed, 27 Jul 2005 22:46:40 GMT
As part of the EG meeting  I was requested to send him an email which 
could in turn be forwarded on to other EG members. A few points before I 

- I wish to apologize in advance as I did a poor job keeping track of 
organizations everyone was associated with and an even worse job with 
names. If I make any mistakes with either I apologize.

- There were two versions of questions in use during the meeting. We 
eventually established that the majority of people had the Kathey's 
version of questions upon which mine were based. These are the questions 
which I will post here. As Kathey pointed out in an earlier email my 
questions can be found at:


- There was some talk on auto-generated numbers for tables that I was 
unprepared for which I will not discuss here as I believe the issue was 
outside the scope of the questions asked by either Kathey or I.

> 1)   The spec says that the result set is closed when invocation of its
> next method returns
> false.  Does this mean an additional call to next should throw an
> exception that the result set is closed or should it just continue to
> return false?

The feedback I got on this issue was mixed. I believe the Oracle 
representative told me that oracle differentiates between traversing 
past the end of the ResultSet and an explicit call to the 
ResultSet#close method by the user. In the former case continued calls 
to ResultSet.next() would always return false whereas in the latter case 
Oracle would throw an Exception. In many cases (the majority?) JDBC 
drivers would return false on calls to ResultSet#next() after the 
completion of the ResultSet. It was generally agreed that the wording of 
section 9.1 of the JDBC 4.0 specification could be improved but people 
were divided on how exactly to improve it. I eagerly await further 
opinions on this issue.

> 5) How should DatabaseMetaData calls affect commit? Since the statement
> itself is not exposed, should  execution of a metadata call send a
> commit or have special handling to avoid this?

Feedback in this area was a bit more firm. It seems there exist JDBC 
drivers where DatabaseMetaData methods that return ResultSets have no 
associated Statement. This means that there is no Statement to complete 
when the ResultSet closes which in turn means that an Auto-Commit is not 
necessary. However, there are also instances where JDBC drivers *must* 
query the database and by the nature of the connection this query *must* 
close other open Statements. It is my understanding that these two sides 
are irreconcilable. Thus the behavior of the DatabaseMetaData object is 
driver and database dependant, so it is open to the Derby community to 
implement DatabaseMetaData Objects in a manner suitable to Derby. 
However it was agreed that changes were needed to the specification to 
alert developers that DatabaseMetaData objects could be implemented in 
either fashion and they should not program in such a way that their code 
was dependant upon either implementation.

> 3)  For callable statements the spec says "the statement is complete
> when all of the associated result sets have been closed"
>    but the setAutoCommit javadoc also seems to require that other
> results such as  results which are update counts and output parameters
> be retrieved.  How do these play into statement completion?

It was agreed that the documentation from the JDBC specification and 
Java Documentation were conflicting. At the same time it was also agreed 
that neither wording was completely right. I proposed (something close 
to) the following amendment to the wording of these documents:

"For CallableStatement objects or for statements that return multiple
results, the statement is complete when:
 - All of the associated result sets have been closed.
 - All of the results (update counts) have been retrieved
 - All output parameters have been retrieved.

There are two problems with this wording:
1) Potential ambiguity with the word 'retrieved'.
2) Special handling of more advanced data types. The two cases raised 
were XML data types and (B?)LOBs.

While the first problem could likely be resolved quickly, the second is 
more problematic.

> 4) (Bonus Question not asked in email by Kathey or I) In the case of 
> conflict between Java Documentation and JDBC 4.0. specification which 
> document should be assumed to be correct?

I believe Lance's answer was neither. Neither document can be taken over 
the other 100% of the time. It is necessary to weigh both inputs and 
make the evaluation as to which is correct. At the same time another 
member of the EG team suggested that if a decision needed to be made and 
there was no clear winner that developers should follow documents in the 
following order:
1) JDBC Specification
2) Java Documentation
3) JDBC Tutorial

I would also encourage Lance to provide his two cents anywhere his 
interpretation of the meeting does not run parallel to his own.


View raw message