Thread: ResultSet internal data type handling

Having a look at jdbc2.AsbtractJDBC2ResultSet (the parent of all ResultSets) I
discovered that all data received from the server is handled internally as a
string (right?) and is converted from the getXXX methods into the appropriate
type. This means that you can actually write a getString on a date field
obtaining a valida date (and if you are lucky you can do something the
opposite). I'm curious to know if this is an implementation choice or a jdbc
specification and why the objects are not checked against the table metadata
(as the getInternalObject method does).

Thanks,
Luca

Luca Ferrari wrote:
> Having a look at jdbc2.AsbtractJDBC2ResultSet (the parent of all ResultSets) I
> discovered that all data received from the server is handled internally as a
> string (right?) and is converted from the getXXX methods into the appropriate
> type. This means that you can actually write a getString on a date field
> obtaining a valida date (and if you are lucky you can do something the
> opposite). I'm curious to know if this is an implementation choice or a jdbc
> specification and why the objects are not checked against the table metadata
> (as the getInternalObject method does).
>
I believe the original wire protocol only supported text values hence
the driver converts all data into a string before sending it to the
server... Because of this the server will generally convert any value
into the appropriate type (if this conversion is possible) which saves
the driver from doing so. This simplifies the driver at the expense of
extra network traffic and errors thrown by the server as opposed to the
driver. The original authors can probably expand on this

Thanks

JOHN

Luca Ferrari wrote:
> Having a look at jdbc2.AsbtractJDBC2ResultSet (the parent of all ResultSets) I
> discovered that all data received from the server is handled internally as a
> string (right?) and is converted from the getXXX methods into the appropriate
> type. This means that you can actually write a getString on a date field
> obtaining a valida date (and if you are lucky you can do something the
> opposite). I'm curious to know if this is an implementation choice or a jdbc
> specification and why the objects are not checked against the table metadata
> (as the getInternalObject method does).

There's a table in the JDBC spec that lists the basic type conversions
that a JDBC driver must support. Most types can be converted to strings,
from memory.

-O

On Tuesday 12 May 2009 10:02:54 am John Lister's cat walking on the keyboard
wrote:

> I believe the original wire protocol only supported text values hence
> the driver converts all data into a string before sending it to the
> server... Because of this the server will generally convert any value
> into the appropriate type (if this conversion is possible) which saves
> the driver from doing so. This simplifies the driver at the expense of
> extra network traffic and errors thrown by the server as opposed to the
> driver. The original authors can probably expand on this


It is not clear to me: the driver is receiving always strings from the server,
and therefore must do the conversion by itself. The fact is that such
conversion is not checked against the table definition. I would expect an
SQLException if I try to read an integer as a string or viceversa. Instead the
conversion can work and the driver says nothing about.

Luca

Luca Ferrari wrote:

> It is not clear to me: the driver is receiving always strings from the server,
> and therefore must do the conversion by itself. The fact is that such
> conversion is not checked against the table definition. I would expect an
> SQLException if I try to read an integer as a string or viceversa. Instead the
> conversion can work and the driver says nothing about.

The JDBC spec says the driver does conversions depending on the
ResultSet getter method you use. See table B-6 in appendix B of the JDBC
spec. In this particular case, the table says you can getInt() on a
VARCHAR and getString() on an INTEGER.

-O

>> I believe the original wire protocol only supported text values hence
>> the driver converts all data into a string before sending it to the
>> server... Because of this the server will generally convert any value
>> into the appropriate type (if this conversion is possible) which saves
>> the driver from doing so. This simplifies the driver at the expense of
>> extra network traffic and errors thrown by the server as opposed to the
>> driver. The original authors can probably expand on this
>>
>
> It is not clear to me: the driver is receiving always strings from the server,
> and therefore must do the conversion by itself. The fact is that such
> conversion is not checked against the table definition. I would expect an
> SQLException if I try to read an integer as a string or viceversa. Instead the
> conversion can work and the driver says nothing about.
>
For outgoing values, the current driver delays doing any work with the
query until it is actually executed. This has a number of consequences
and benefits which have been discussed before - see threads about
preparedstatements, etc. The double edged sword of this is that by
delaying execution the driver knows the types of the parameters being
passed in which can help planning, the downside is that it doesn't know
the types required so can't generate errors. While it is true that if
the query is fairly simple and done against a table then it could make
the check before submitting the query. But what does it do for queries
like this:

SELECT ?

The parameter can be of any type. Generally the argument is that you
cannot know the param types from the query itself.

However for incoming values/conversions, as oliver mentioned the JDBC
spec requires a driver do some conversions automatically (int -> string).

JOHN