Обсуждение: 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