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
begin:
- 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:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL
PROTECTED]
- 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.
Philip
