Обсуждение: ResultSetMetaData + CachedResultSet bug

Hello everybody!

    Today I have found a strange bug in JDBC driver (I used the last version avilable - 8.2dev-503). The problem is
withVARCHAR  
fields - driver returns "-1" on "getPrecision()" call. But class javax.sql.rowset.RowSetMetaDataImpl in its
"setPrecision()"method  
requires values of 0 and more (javadoc sais "precision the total number of decimal digits; must be <code>0</code> or
more"). 
I understand that in case of VARCHAR type we cannot speak about real number of decimal digits - but could just driver
return0  
instead of -1?
    Please advise.

    Thanks in advance for answer.

---
WBR, Sergii Sinelnychenko
Senior Java Developer, Project Manager
e: SSinelnychenko@bossdev.com
w: www.bossdev.com

On Thu, 22 Jun 2006, Sergii Sinelnychenko wrote:

>   Today I have found a strange bug in JDBC driver (I used the last version
> avilable - 8.2dev-503). The problem is with VARCHAR fields - driver returns
> "-1" on "getPrecision()" call. But class javax.sql.rowset.RowSetMetaDataImpl
> in its "setPrecision()" method requires values of 0 and more (javadoc sais
> "precision the total number of decimal digits; must be <code>0</code> or more
> ").
> I understand that in case of VARCHAR type we cannot speak about real number
> of decimal digits - but could just driver return 0 instead of -1?


That certainly looks like a reasonable thing to do for text types.  The
one case that needs a little more thinking about is a numeric field that
has neither precision nor scale supplied.  For this we currently return -1
for both precision and scale.  The maximum precision of a numeric is 1000
digits, so we could divy it up evenly and make an unadorned numeric be
returned as numeric(1000,500), but that seems a little too much like just
making things up.  Thoughts?

Kris Jurka

Kris Jurka wrote:
>
>
> On Thu, 22 Jun 2006, Sergii Sinelnychenko wrote:
>
>>   Today I have found a strange bug in JDBC driver (I used the last
>> version avilable - 8.2dev-503). The problem is with VARCHAR fields -
>> driver returns "-1" on "getPrecision()" call. But class
>> javax.sql.rowset.RowSetMetaDataImpl in its "setPrecision()" method
>> requires values of 0 and more (javadoc sais "precision the total
>> number of decimal digits; must be <code>0</code> or more ").
>> I understand that in case of VARCHAR type we cannot speak about real
>> number of decimal digits - but could just driver return 0 instead of -1?
>
>
> That certainly looks like a reasonable thing to do for text types.  The
> one case that needs a little more thinking about is a numeric field that
> has neither precision nor scale supplied.  For this we currently return
> -1 for both precision and scale.  The maximum precision of a numeric is
> 1000 digits, so we could divy it up evenly and make an unadorned numeric
> be returned as numeric(1000,500), but that seems a little too much like
> just making things up.  Thoughts?
>
I think the current -1 is reasonable for non numeric types. For the numeric types however,
the interpretation should be that 0 is unlimited. A numeric should never return -1 and
should accept setPrecision(colidx, 0) as 'no limit', i.e.

  0 = unlimited
-1 = not applicable

A setPrecision call on types where precision has no meaning should IMO yield an exception.

The rationale is that a) stating that a varchar has zero decimal digits is wrong since it
doesn't have any notion of decimal digits, and b) a precision of zero for a numeric doesn't
make sense when interpreted verbatim.

Regards,
Thomas Hallgren

On Fri, 30 Jun 2006, Thomas Hallgren wrote:

> I think the current -1 is reasonable for non numeric types. For the numeric
> types however, the interpretation should be that 0 is unlimited. A numeric
> should never return -1 and should accept setPrecision(colidx, 0) as 'no
> limit', i.e.
>
> 0 = unlimited
> -1 = not applicable
>
> A setPrecision call on types where precision has no meaning should IMO yield
> an exception.
>
> The rationale is that a) stating that a varchar has zero decimal digits is
> wrong since it doesn't have any notion of decimal digits, and b) a precision
> of zero for a numeric doesn't make sense when interpreted verbatim.

I'm not sure what the harm in using zero for text types' precision is.
Yes, I agree it'd be best if all applications were smart enough to use the
type information correctly, but they're not.  Especially when it's
something in the standard JDK that everyone uses I think we should try to
work around it if we can.

What about scale for an unspecified numeric?  zero is a legitimate scale
so that can't be used for unlimited, but RowSetMetaDataImpl doesn't like
anything < 0.

Kris Jurka

On Fri, 30 Jun 2006, Thomas Hallgren wrote:

> Kris Jurka wrote:
>>
>> [what to do about precision for non-numeric types]
>>
> I think the current -1 is reasonable for non numeric types. For the numeric
> types however, the interpretation should be that 0 is unlimited. A numeric
> should never return -1 and should accept setPrecision(colidx, 0) as 'no
> limit', i.e.
>
> 0 = unlimited
> -1 = not applicable
>
> The rationale is that a) stating that a varchar has zero decimal digits is
> wrong since it doesn't have any notion of decimal digits, and b) a precision
> of zero for a numeric doesn't make sense when interpreted verbatim.
>

The latest javadocs have clarified what they expect precision to mean for
non-numeric datatypes.

http://download.java.net/jdk6/docs/api/java/sql/ResultSetMetaData.html#getPrecision(int)

I've adjusted the driver to follow the new rules and not return -1
anymore.

Kris Jurka