Thread: getXXX methods
There is a table in the jdbc spec which suggests that there is a preferred method for getting the column information, and at non-preferred method. For example getByte can be used to get a: byte --- obviously short long real float double decimal numeric bit char varchar longvarchar Currently this is not implemented as such, there are a few questions I have though would all the numeric values be truncated ? What do we do with char, varchar, longvarchar ? -- Dave Cramer 519 939 0336 ICQ # 14675561 www.postgresintl.com
On Fri, 2 Jul 2004, Dave Cramer wrote: > There is a table in the jdbc spec which suggests that > there is a preferred method for getting the column information, and at > non-preferred method. > > would all the numeric values be truncated ? > > What do we do with char, varchar, longvarchar ? It's tough to say. Looking at the current situation for retrieving double values with getInt() the current driver will throw an Exception on a out of range value because it starts with a String and uses Integer.parseInt() on it. Contrast this with the result of Double d = new Double(Double.MAX_VALUE); System.out.println(d.intValue()); which truncates the double to Integer.MAX_VALUE. The javadocs are useless, but I prefer the Exception to silent truncation, so I would suggest getByte can be used on any integer value of -128 to 127 regardless of its storage form (like text). The question of comparing floating point numbers should be the same, but we may run into problems when 1 is represented as 1.00000001. Kris Jurka
Once possibility is to use Double.parseDouble(s).byteValue()
so the code would become
try
{
Byte.parseByte(s)
}
catch(NumberFormatException e)
{
try
{
return Double.parseDouble(s).ByteValue();
}
catch( NumberFormatException ne )
{
throw exception;
}
}
Dave
On Tue, 2004-07-06 at 14:46, Kris Jurka wrote:
> On Fri, 2 Jul 2004, Dave Cramer wrote:
>
> > There is a table in the jdbc spec which suggests that
> > there is a preferred method for getting the column information, and at
> > non-preferred method.
> >
> > would all the numeric values be truncated ?
> >
> > What do we do with char, varchar, longvarchar ?
>
> It's tough to say. Looking at the current situation for retrieving double
> values with getInt() the current driver will throw an Exception on a out
> of range value because it starts with a String and uses Integer.parseInt()
> on it. Contrast this with the result of
>
> Double d = new Double(Double.MAX_VALUE);
> System.out.println(d.intValue());
>
> which truncates the double to Integer.MAX_VALUE. The javadocs are
> useless, but I prefer the Exception to silent truncation, so I would
> suggest getByte can be used on any integer value of -128 to 127 regardless
> of its storage form (like text). The question of comparing floating point
> numbers should be the same, but we may run into problems when 1 is
> represented as 1.00000001.
>
> Kris Jurka
>
>
>
> !DSPAM:40eaf9e7148133410918667!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
On Tue, 6 Jul 2004, Dave Cramer wrote:
> Once possibility is to use Double.parseDouble(s).byteValue()
>
> so the code would become
>
> try
> {
> Byte.parseByte(s)
> }
Why bother with Byte.parseByte at all if you are going to fall back to the
double parsing anyway? As I mentioned earlier I think it is better to
throw an Exception rather than to silently alter the returned data.
Kris Jurka
I was thinking that parsing the double would be less efficient than
Byte.parseByte().
The spec suggests that the user would know what they are doing calling
getByte on a double column.
Dave
On Tue, 2004-07-06 at 17:01, Kris Jurka wrote:
> On Tue, 6 Jul 2004, Dave Cramer wrote:
>
> > Once possibility is to use Double.parseDouble(s).byteValue()
> >
> > so the code would become
> >
> > try
> > {
> > Byte.parseByte(s)
> > }
>
> Why bother with Byte.parseByte at all if you are going to fall back to the
> double parsing anyway? As I mentioned earlier I think it is better to
> throw an Exception rather than to silently alter the returned data.
>
> Kris Jurka
>
>
>
> !DSPAM:40eb133321082025652008!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
Dave Cramer wrote: > I was thinking that parsing the double would be less efficient than > Byte.parseByte(). > > The spec suggests that the user would know what they are doing calling > getByte on a double column. Yeah, specifically table B-6 says you can use getByte() on pretty much any numeric SQL type, and (bizarrely) on varchar, char, longvarchar, and boolean types too. The spec & javadoc for java.sql.DataTruncation implies we should generate DataTruncation as a warning if we truncate data on read. I suppose that loss of precision counts as truncation? -O
Oliver, Well as Kris pointed out the javadoc is next to useless here. I see no harm in truncating the data, my assumption being that the user knows what they are doing. Dave On Tue, 2004-07-06 at 19:40, Oliver Jowett wrote: > Dave Cramer wrote: > > I was thinking that parsing the double would be less efficient than > > Byte.parseByte(). > > > > The spec suggests that the user would know what they are doing calling > > getByte on a double column. > > Yeah, specifically table B-6 says you can use getByte() on pretty much > any numeric SQL type, and (bizarrely) on varchar, char, longvarchar, and > boolean types too. > > The spec & javadoc for java.sql.DataTruncation implies we should > generate DataTruncation as a warning if we truncate data on read. I > suppose that loss of precision counts as truncation? > > -O > > > > !DSPAM:40eb3871277871679725527! > > -- Dave Cramer 519 939 0336 ICQ # 14675561
Dave Cramer wrote: > Oliver, > > Well as Kris pointed out the javadoc is next to useless here. I see no > harm in truncating the data, my assumption being that the user knows > what they are doing. If the application really wants silent truncation without warning can't they do it directly in the query? I think generating DataTruncation (nb: as a *warning*, not throwing an exception) is still a good idea. Then at least the application gets some sort of notification. Have you read the DataTruncation javadoc & spec section? -O
hmmm... Ok, just read it. Presumably the warning would be added to the result set object? I doubt this was the intended use as the table infers that using any of the non-preferred methods will cast to the requested type. I do see this as a good thing assuming the programmer is aware of the warnings, and is handling them. I do have one concern however: Lets suppose that the user gets a very large result set and starts scrolling through it, we keep adding warnings to it and we run out of memory? Dave On Tue, 2004-07-06 at 21:10, Oliver Jowett wrote: > Dave Cramer wrote: > > Oliver, > > > > Well as Kris pointed out the javadoc is next to useless here. I see no > > harm in truncating the data, my assumption being that the user knows > > what they are doing. > > If the application really wants silent truncation without warning can't > they do it directly in the query? > > I think generating DataTruncation (nb: as a *warning*, not throwing an > exception) is still a good idea. Then at least the application gets some > sort of notification. > > Have you read the DataTruncation javadoc & spec section? > > -O > > > > !DSPAM:40eb4d8f105802968417614! > > -- Dave Cramer 519 939 0336 ICQ # 14675561
On Wed, 7 Jul 2004, Oliver Jowett wrote: > If the application really wants silent truncation without warning can't > they do it directly in the query? > > I think generating DataTruncation (nb: as a *warning*, not throwing an > exception) is still a good idea. Then at least the application gets some > sort of notification. > > Have you read the DataTruncation javadoc & spec section? > It makes sense to me on the write side where a database could truncate data to a varchar(N) column instead of erroring, but pg considers this and numeric out of range values as errors. On the read side assuming that the user "knows what they are doing" seems wrong. Consider a likely situation like a int8 column value being retrieved with getInt(), it works fine for years, but once hitting the limit on integer size a truncation would cause bizarre application errors. Section 8.3.1 of the spec clearly seems to indicate that a silent truncation is a special case and that shouldn't be our behavior for other data types than those specifically affected by setMaxFieldSize(). The DataTruncation API is organized around byte sizes and just doesn't seem right for numeric data. Even if the spec does imply that a warning shuold be issued (which is not clear to me), I can't imagine why anyone would want this. If I want truncation I'll do it myself, otherwise I want any error to immediately raise a red flag and put the brakes on processing. How many people really check for warnings anyway? Kris Jurka
Kris Jurka wrote: > The > DataTruncation API is organized around byte sizes and just doesn't seem > right for numeric data. There is support throughout that API for "unknown sizes" which seems appropriate when you're not dealing with explicitly-sized types. And even types such as varchar don't map directly to bytes anyway.. > Even if the spec does imply that a warning > shuold be issued (which is not clear to me), I can't imagine why > anyone would want this. If I want truncation I'll do it myself, otherwise > I want any error to immediately raise a red flag and put the brakes on > processing. I tend to agree -- but Dave evidently has a use for it, in which case truncation+warning seems a lesser evil than silent truncation. > How many people really check for warnings anyway? I hate this argument. If we don't generate any warnings, of course no one will check for them! -O
On Wed, 7 Jul 2004, Oliver Jowett wrote: > > How many people really check for warnings anyway? > > I hate this argument. If we don't generate any warnings, of course no > one will check for them! No, this is different. Exceptions are supposed to prevent you from checking the return code on every function call, which the warning API seems to want to you to do. Kris Jurka
Ok, it appears (at least from my understanding) that Kris is correct here. I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and it states: A number is assignable only to sites of numeric type. If an assignment of some number would result in a loss of it's most significant digit, an exception conditions is raised. If least significant digits are lost, implementation defined rounding, or truncation occurs, with no exception condition being raised. Dave On Tue, 2004-07-06 at 21:58, Kris Jurka wrote: > On Wed, 7 Jul 2004, Oliver Jowett wrote: > > > > How many people really check for warnings anyway? > > > > I hate this argument. If we don't generate any warnings, of course no > > one will check for them! > > No, this is different. Exceptions are supposed to prevent you from > checking the return code on every function call, which the warning API > seems to want to you to do. > > Kris Jurka > > > > !DSPAM:40eb58bf196361343028809! > > -- Dave Cramer 519 939 0336 ICQ # 14675561
On Wed, 7 Jul 2004, Dave Cramer wrote: > Ok, it appears (at least from my understanding) that Kris is correct > here. > > I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and > it states: Well the SQL spec and the JDBC spec are different things. I was basing part of my argument on the SQL spec's logic and extending that to fill in the holes in the JDBC spec, but I don't consider this definitive. I still feel this is the right thing to do, but I don't want to close off the discussion if people feel otherwise. Kris Jurka
I think that since the SQL spec is referenced at the end of the JDBC spec that it has some relevance. I just thought that in absence of a second, or third opinion this would suggest a course of action? Dave On Thu, 2004-07-08 at 02:50, Kris Jurka wrote: > On Wed, 7 Jul 2004, Dave Cramer wrote: > > > Ok, it appears (at least from my understanding) that Kris is correct > > here. > > > > I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and > > it states: > > Well the SQL spec and the JDBC spec are different things. I was basing > part of my argument on the SQL spec's logic and extending that to fill in > the holes in the JDBC spec, but I don't consider this definitive. I still > feel this is the right thing to do, but I don't want to close off the > discussion if people feel otherwise. > > Kris Jurka > > > > !DSPAM:40eceebb46734039016794! > > -- Dave Cramer 519 939 0336 ICQ # 14675561
Well, I have an interesting problem... Detecting that a value is greater than MaxLong? If I parse it using Double.parseDouble, and it is greater than LongMax by 1 or so, the value ends up actually being less due to rounding ? Any suggestions? Dave On Thu, 2004-07-08 at 08:11, Dave Cramer wrote: > I think that since the SQL spec is referenced at the end of the JDBC > spec that it has some relevance. I just thought that in absence of a > second, or third opinion this would suggest a course of action? > > Dave > On Thu, 2004-07-08 at 02:50, Kris Jurka wrote: > > On Wed, 7 Jul 2004, Dave Cramer wrote: > > > > > Ok, it appears (at least from my understanding) that Kris is correct > > > here. > > > > > > I had a look at the sql2003 proposed spec (ISO/IEC 9075-2:2003(E)), and > > > it states: > > > > Well the SQL spec and the JDBC spec are different things. I was basing > > part of my argument on the SQL spec's logic and extending that to fill in > > the holes in the JDBC spec, but I don't consider this definitive. I still > > feel this is the right thing to do, but I don't want to close off the > > discussion if people feel otherwise. > > > > Kris Jurka > > > > > > > > > > > > -- Dave Cramer 519 939 0336 ICQ # 14675561
Dave Cramer wrote: > Well, I have an interesting problem... > > Detecting that a value is greater than MaxLong? > > If I parse it using Double.parseDouble, and it is greater than LongMax > by 1 or so, the value ends up actually being less due to rounding ? > > Any suggestions? The problem is that you're going via a double, you're going to lose precision there regardless of what you do (you don't have 64 bits of mantissa+sign to play with). If you want to retain precision, don't use a double as your intermediate value. Perhaps extract everything before the first '.' and use parseLong? That will truncate rather than round the value though. I don't like the whole idea of silently losing data anyway.. -O