>>>>>>>>>>>> Lance J. Andersen wrote (2006-01-06 09:14:46): > The spec needs to be followed whether you agree or disagree with the > semantics. The javadocs are very specific here and there must have been > a reason for this decision at the time. As i indicated to Craig, I am > trying to find out if any of the previous spec leads recall why this was > done before i do anything else on this issue.
I agree that we need to follow the specs. Just wondered what Craig thought his "big unfounded claim" would imply..... ;-) > A change in this area could potentially break existing applications who > are relying on the functionality as documented. This would have to be > weighed by the JDBC EG prior to any changes in behavior. > > It is just not a simple change the javadocs at this time. This has to > be researched and discussed further. It could well be that no one is > impacted, i just do not know at this point in time. > > Regards > Lance > Bernt M. Johnsen wrote: > > >>>>>>>>>>>>>Craig L Russell wrote (2006-01-05 16:59:00): > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>Hi, > >> > >>I asked Lance Anderson, spec lead for JDBC 4.0, about this issue and > >>he replied that he thinks that due to compatibility with existing > >>applications that rely on this behavior, it's unlikely to change. > >> > >>My opinion is that the behavior is surprising, and that most > >>applications that discover that the API with a BigDecimal parameter > >>truncates all the decimals, simply change to the API call that allows > >>you to specify the scale. > >> > >>So my big unfounded claim is that there is no use for the API without > >>the scale parameter taking a BigDecimal parameter with the current > >>behavior. And that changing it has low risk of untoward results. > >> > >> > > > >Do you suggest that we should throw an exception if setObject without > >scale is called with a BigDecimal argument? Or do you suggest that we > >let setObject default to the scale of the BigDecimal parameter and > >thus violating the spec? > > > >Bernt > > > > > > > > -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
pgpzAbEOUNqec.pgp
Description: PGP signature
