db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: behavior of Statement.getGeneratedKeys()
Date Tue, 11 Jul 2006 20:33:48 GMT
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 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 autogenerated column in the 
> affected table; that is, the column could have type SMALLINT, INT, or 
> 3) It does not seem that this change would have a very big impact on 
> customers. At least, we have not been able to imagine how this would 
> impact customers adversely. However, this is just theory and we have 
> not polled the user community yet.

We not only have not polled the user community, we do not have anything 
we can poll them with yet.  getGeneratedKeys returns a result set.  
Users will call certain methods on  that  ResultSet and the return 
values will be different.   We need to define what those are and the 
potential impact.  Then we map them to the user symptom and then we can 
define scenarios that might be affected.  If it is important  that we 
break our current documented behavior we have to take these painful 
steps to assess  risk.  A vague poll without understanding  the possible 
impact ourselves and presenting it clearly is not effective  or fair to 
the user base as we found with DERBY-1459.  

Can you please complete the list below with any other changes  in the 
result set returned by getGeneratedKeys or  confirm that there are no 
other calls impacted?  Let's not include the likely of each happening 
yet.  We just want to understand what has changed and what symptoms 
users might see.
I agree with what we have so far the risk is low but w need to go 
through the whole exercise.  How has the result set returned changed?  
What symptoms might users see?    Define user scenarios and risk. Then 
poll the user community.

Certainly there would be  these changes for the ResultSet returned by 

o  getMetaData()  would  correspond to the ResultSetMetadata of the base 
table column and so will have different types, columnwidths etc, so 
formatting and other decisions based on this information may be affected.
o  getObject()  would  return a different type and applications making 
casts based on the assumption it is a BigDecimal  may see cast 
exceptions or other problematic behavior because of this assumption.
o getString()  would return a different String representation which  
might  be problematic if a particular format was expected and  parsed.

Would other ResultSet methods might be affected?  For instance,  would 
getInt(), getLong(), getShort()  etc. all still work as they did before 
and return the same values?

> So what do we think?
> A) Does anyone prefer the current behavior over Lance's proposed 
> behavior?

Only in that it saves a lot of time in risk assesssment  and not 
changing it prevents us from setting  a precedent for changing 
documented and compliant behaviour to something else with no really 
significant benefit to users, but rather just the sake of tidiness and 
the convenience of writing code that is not guaranteed to be portable to 
other JDBC Drivers.

Also I would think the client implementation might be a little hairy. 
We'd need to make a new system procedure returning a result set and 
there would be mixed version compatibility issues no doubt and maybe 
transactional related issues and  I'm not so keen on reviewing all that, 
but of course if someone wants to invest their time in it,  the review 
time  is just the price I pay for being a compatibility zealot.

One possible other benefit and I think the one that Lance is getting at 
with the change is that if changed,  Derby could over time become a 
defacto standard and help clarify the spec for new JDBC Driver 
implementations .   It is probably the best reason I see for the change 
and an interesting role for Derby to play. If that is the reason why we 
are doing it, that should be a conscious decision.

> B) Does this kind of change violate our policies for minor releases?
 I think  the main thing is that breaking compatibility just has to be a 
conscious decision by the community.  Once the analysis is made that 
decision can happen.

> C) Are there other objections to this change?
I think due diligence is needed as described above.  If that is done and 
there is no further impact identified I wouldn't veto it, but without it 
I would.

> D) Would we like to poll the user community now?
No see above.

View raw message