[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12375156 ]
Rick Hillegas commented on DERBY-925:
-
I will take a look at this patch and run the tests. Cheers-Rick
Implement new JDBC 4 metadata API getFunctionParameters()
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12375207 ]
Rick Hillegas commented on DERBY-925:
-
Looks solid thanks to the thoughtful discussion which preceded this patch.
JDBC4 tests pass cleanly. Derbyall passes modulo
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12369670 ]
Dyre Tjeldvoll commented on DERBY-925:
--
Knut Anders Hatlen wrote in a message to derby-dev:
getFunctionParameters() and getFunctions() are not implemented (not
even to
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12369193 ]
Dyre Tjeldvoll commented on DERBY-925:
--
First of all, metadata.properties WILL have to change for JDBC 4.0, and it
already has. David has already added new queries for
David Van Couvering (JIRA) derby-dev@db.apache.org writes:
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12369276
]
David Van Couvering commented on DERBY-925:
---
The network client currently returns a Not Implemented
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12369129 ]
Kathey Marsden commented on DERBY-925:
--
I'm interested to know the behaviour
- if Server is at 10.1 and Client is at 10.2
- If server and client are at different jvm
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368699 ]
Dyre Tjeldvoll commented on DERBY-925:
--
I just realized that DatabaseMetaData.getProcedureColumns() has been changed in
JDBC 4.0. The result set it returns now conatains
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368708 ]
Knut Anders Hatlen commented on DERBY-925:
--
Dyre wrote:
I just realized that DatabaseMetaData.getProcedureColumns() has been
changed in JDBC 4.0. The result set it
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368709 ]
Dyre Tjeldvoll commented on DERBY-925:
--
I agree, no separate JDBC4 implementation should be necessary. But I was
thinking that we could have multiple queries in
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368710 ]
Knut Anders Hatlen commented on DERBY-925:
--
Keeping the master files unmodified is not very important. If the output is
different with the JDBC 3.0 driver and the
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368724 ]
Daniel John Debrunner commented on DERBY-925:
-
Single implementation for 3.0 and 4.0 seems ok to me, changing master files or
not should not be a decision factor
Hi Lance,
Is it OK for a JDBC3 implementation to return more information than the
spec demands? In particular, consider the various result sets returned
by DatabaseMetaData calls. Is it OK for these result sets to contain
additional, trailing columns, above and beyond the columns required by
Someday, we may start converting legacy tests to an assertion-based
model. When we do that, I recommend starting with these tests which have
generated a spray of different canons for different platforms.
Regards,
-Rick
Knut Anders Hatlen (JIRA) wrote:
[
Rick Hillegas wrote:
Hi Lance,
Is it OK for a JDBC3 implementation to return more information than the
spec demands? In particular, consider the various result sets returned
by DatabaseMetaData calls. Is it OK for these result sets to contain
additional, trailing columns, above and beyond
I have noticed on the JDBC4 EG mailing list that this method appears to
be going through revisions. Lance, do you have the latest on this?
David
Dyre Tjeldvoll (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368699 ]
Dyre Tjeldvoll commented on
Daniel John Debrunner [EMAIL PROTECTED] writes:
Rick Hillegas wrote:
Hi Lance,
Is it OK for a JDBC3 implementation to return more information than the
spec demands? In particular, consider the various result sets returned
by DatabaseMetaData calls. Is it OK for these result sets to
[EMAIL PROTECTED] wrote:
On a related note, getProcedureColumns() already does that today. The
returned result set has two additional columns (METHOD_ID
PARAMETER_ID) that aren't part of the spec. This does not seem to
cause any problems, but where should these two columns go when we add
7 new
No revisions to getFunctionParameters. this was settled in Dec, just EG
confusion. Only thing i changed was the constant
functionParameterReturn to functionReturn as i missed this earlier.
-lance
David W. Van Couvering wrote:
I have noticed on the JDBC4 EG mailing list that this method
We had a long EG discussion on this and the wording changes was the only
way we could provide portability and extendability going forward.
Having vendors just throw their own entries into the ResultSet is not
very portable either nor is the ODBC way of changing column names which
is something
Hi Rick,
There is a limited number of DatabaseMetaData methods have allowed this
to occur as part of the functionality. This was unfortunate IMHO.
-lance
Rick Hillegas wrote:
Hi Lance,
Is it OK for a JDBC3 implementation to return more information than
the spec demands? In particular,
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12367959 ]
Dyre Tjeldvoll commented on DERBY-925:
--
I have some questions about the columns in the resultset that is returned from
this method.
Abbreviations:
[
http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12367858 ]
Dyre Tjeldvoll commented on DERBY-925:
--
As far as I can tell it is not possible to obtain all the necessary information
from Derby's existing system tables. The
22 matches
Mail list logo
