Kathey Marsden wrote:
Another similar case is DERBY-1501 where it
would be nice if Derby were more forgiving of non-portable apps. Of
course in both of those other cases we would just be adding to existing
support, not changing existing behavior and `there is a risk to apps
that develop
Daniel John Debrunner wrote:
Kathey Marsden wrote:
Another similar case is DERBY-1501 where it
would be nice if Derby were more forgiving of non-portable apps. Of
course in both of those other cases we would just be adding to existing
support, not changing existing behavior
Lance J. Andersen wrote:
With 1501 the JDBC spec says the type must be known (I think it's a bug
in the *draft* spec for the type to be ignored), that's the portable
behaviour, ignoring the type not only leads to non-portable applications
but also inconsistencies in derby. E.g. a NULL defined
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
With 1501 the JDBC spec says the type must be known (I think it's a bug
in the *draft* spec for the type to be ignored), that's the portable
behaviour, ignoring the type not only leads to non-portable applications
but
this is not a bug.
2) Lance would like to change the behavior of
Statement.getGeneratedKeys(). Currently this method always returns a
ResultSet whose column has the canonical type DECIMAL( 31, 0). He
would like this method to return a ResultSet whose column type
changes depending on the type of the actual
Lance J. Andersen wrote:
I discussed this briefly at my JDBC EG meeting yesterday.
As i expected, all of the vendors on the call indicated that they return
the same data type for key returned in the case of column defined as
identity via the getGeneratedKeys() method. The consensus was
I think it can be improved but the javadocs indicates (executeUpdate)
that the array is ignored if the statement is not able to return an
autogenerated key and the getGeneratedKeys says it will return an empty
ResultSet if it cannot return generated keys.
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
This issue pointed out a problem in the JDBC EoD RI which made the
assumption that the value returned matched the column type in the base
table.
A Derby user encountered this issue as well, trying to use 10.2 and
JDBC EoD
Kathey Marsden wrote:
Lance J. Andersen wrote:
This issue pointed out a problem in the JDBC EoD RI which made the
assumption that the value returned matched the column type in the
base table.
A Derby user encountered this issue as well, trying to use 10.2 and
JDBC EoD
Lance J. Andersen wrote:
I think it can be improved but the javadocs indicates (executeUpdate)
that the array is ignored if the statement is not able to return an
autogenerated key and the getGeneratedKeys says it will return an empty
ResultSet if it cannot return generated keys.
Do the
Somehow I managed to get into a side conversation with Lance, in the
follow up of this. I am not sure how I did it with my mailer, but I
responded directly to him. Below is my response to Lance which is
relevant to this issue. I will send a separate mail with additional
follow-up which
It's not entirely clear to me that Derby is not compliant.
I do not believe i indicated it was or was not compliant, my point was
is the data type is not what i would expect returned in this scenario.
The ResultSetMetaData does correctly described the number, type and
properties of the
Kathey Marsden wrote:
Rick Hillegas wrote:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the underyling
autogenerated column?
Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that
we are not compliant and if
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the underyling
autogenerated column?
Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me
that we are
I'd like to try to summarize where I think the discussion stands:
1) Lance, our JDBC expert, has confirmed that this is not a compliance
problem. That means this is not a bug.
2) Lance would like to change the behavior of
Statement.getGeneratedKeys(). Currently this method always returns
Rick Hillegas wrote:
I'd like to try to summarize where I think the discussion stands:
1) Lance, our JDBC expert, has confirmed that this is not a compliance
problem. That means this is not a bug.
2) Lance would like to change the behavior of
Statement.getGeneratedKeys(). Currently
.
2) Lance would like to change the behavior of
Statement.getGeneratedKeys(). Currently this method always returns a
ResultSet whose column has the canonical type DECIMAL( 31, 0). He
would like this method to return a ResultSet whose column type
changes depending on the type of the actual
I would like the community's advice on whether the following Derby
behavior is a bug and, if so, whether we would be allowed to change this
behavior for 10.2:
A) Currently, Derby knows how to automatically generate values for
columns of type SMALLINT, INT, and BIGINT. You get this behavior if
To me this is a problematic issue as i would expect the return type for
the keys to match the datatype of the column.
Rick Hillegas wrote:
I would like the community's advice on whether the following Derby
behavior is a bug and, if so, whether we would be allowed to change
this behavior for
Rick Hillegas wrote:
Before filing a bug on this, I'd like the community's advice:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the underyling
autogenerated column?
2) If this is a bug, is it permitted to change this behavior in
Hi Kathey,
My gut feeling is that changing this behavior could affect applications
like ij which make formatting decisions based on the JDBC types of
returned columns.
Kathey Marsden wrote:
Rick Hillegas wrote:
Before filing a bug on this, I'd like the community's advice:
1) Is this a
Rick Hillegas wrote:
Hi Kathey,
My gut feeling is that changing this behavior could affect
applications like ij which make formatting decisions based on the JDBC
types of returned columns.
I agree, but I am not sure yet how significant that impact might be. I'd
like translate it into
Kathey Marsden wrote:
Rick Hillegas wrote:
Hi Kathey,
My gut feeling is that changing this behavior could affect
applications like ij which make formatting decisions based on the
JDBC types of returned columns.
If you return the correct column type of the base type, then the
formatting
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
Before filing a bug on this, I'd like the community's advice:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the underyling
autogenerated column?
2) If this is a
Lance J. Andersen wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
Certainly there are these changes for the ResultSet returned by
getGeneratedKeys():
o getMetaData() would correspond to the ResultSetMetadata of the
base table column and so will have different types, columnwidths
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
Before filing a bug on this, I'd like the community's advice:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
This would help customers who want to get the type of a table's
generated key from getGeneratedKeys() itself and not have to extract
this information from a more complicated series of metadata calls.
I'm lost
These seem reasonable. On the other hand, using getGeneratedKeys() to
determine the type name of a table's generated key seems very very
unlikely to me. It would require that the application/tool can insert a
row of the correct shape, if the app/tool can do that, then it probably
Daniel John Debrunner wrote:
Lance J. Andersen wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
Certainly there are these changes for the ResultSet returned by
getGeneratedKeys():
o getMetaData() would correspond to the
Rick Hillegas wrote:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the underyling
autogenerated column?
Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that
we are not compliant and if non-compliance is a bug,
Kathey Marsden wrote:
Rick Hillegas wrote:
1) Is this a bug? Should Statement.getGeneratedKeys() return a
ResultSet whose column has the same type as the underyling
autogenerated column?
Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that
we are not compliant and if
31 matches
Mail list logo
