ResultSetMetaData + CachedResultSet bug
Sergii Sinelnychenko
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?
Please advise.
Thanks in advance for answer.
---
WBR, Sergii Sinelnychenko
Senior Java Developer, Project Manager
e: SSineln...@bossdev.com
w: www.bossdev.com
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Kris Jurka
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Thomas Hallgren
>
>
> 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?
>
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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Kris Jurka
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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?