This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

retrieving null values from ResultSet

 
Dan Murphy
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

When I call ResultSet.getInt() the method will return 0 if the column value is either 0 or null, which is extremely inconvenient, because in many (maybe most) cases, one needs to distinguish between 0 and null. Now I realise that I can use ResultSet.wasNull() to distinguish between 0 and null, but what I don't understand is why the API was defined like this?

If ResultSet.getInt() was defined to return an Integer instead of an int, then it could return either 0 or null, as appropriate, so why wasn't it done like this? This seems like such an obvious mistake that I'm sure I must be missing something. Incidentally, this analysis is equally applicable to various other methods of ResultsSet such as getFloat().

Cheers,
Dan
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't think of a good reason. Just a plain poor design choice perhaps?

Just so you know, this is the sort of problem that ORM frameworks fix.
 
Dan Murphy
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Thanks for the response. I know this problem doesn't exist when using ORM frameworks like Hibernate, but for the forseeable future I'm stuck with JDBC (actually Spring-JDBC which is a lot nicer than raw JDBC).

I suppose I'll just have to write a bunch of wrapper methods like this:




As a bonus question, I'd like to write a single generic getNullableValue() method, instead of separate methods: getNullableInt(), getNullableFloat(), etc. I've written the following, but am not at all satisfied with it, because:

1. It requires an extra 'dummy' parameter whose only purpose is to indicate the desired return type
2. It relies on casting




Can anybody improve on this?

Cheers,
Dan
[ April 15, 2008: Message edited by: Dan Murphy ]
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34671
367
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dan Murphy:
If ResultSet.getInt() was defined to return an Integer instead of an int, then it could return either 0 or null, as appropriate, so why wasn't it done like this?

Just speculating, but maybe it was so the caller wouldn't need to call .intValue() to get the int? I know in my apps, we use "int" a lot more than Integer. (Pre Java 5 this distinction matters as it easier to work with primitives.) Also in my apps, null isn't used often for int fields. We tend to use int's more for types which are always defined. So for me, the interface seems more natural.

Why don't you want individual getNullableInt, String, etc methods? It's library code, so you'd only have to write it once and I can't imagine it changing often. The passing a dummy parameter to signify the type seems more awkward than having it in the name - unless you are selecting the type dynamically of course.
 
Dan Murphy
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Just speculating, but maybe it was so the caller wouldn't need to call .intValue() to get the int? I know in my apps, we use "int" a lot more than Integer. (Pre Java 5 this distinction matters as it easier to work with primitives.)

Perhaps, but since Java 5 Integers are just as easy to work with as ints, so for the last 3/4 years this argument doesn't apply. I really think this should have been 'fixed' by now.

Why don't you want individual getNullableInt, String, etc methods?

It's no big deal really, I'm just curious to know if there's a better way

The passing a dummy parameter to signify the type seems more awkward than having it in the name

I totally agree that the implementation above sucks, though it's not so different from:
List.toArray(T[] a)

[ April 16, 2008: Message edited by: Dan Murphy ]
[ April 16, 2008: Message edited by: Dan Murphy ]
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34671
367
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dan Murphy:
Perhaps, but since Java 5 Integers are just as easy to work with as ints, so for the last 3/4 years this argument doesn't apply. I really think this should have been 'fixed' by now.

Sun is big on backward compatibility. If getInt() changed behavior, it could potentially break something. They would have to use something like getNullableInt() or getInteger() - which actually seems like a nice idea.
 
Stevi Deter
Ranch Hand
Posts: 265
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personally, I far prefer the generics version of the method. It's far more maintainable to have one method versus one per type!

Since you have the type in the call, e.g. getNullableValue(Integer.class,...), it seems a far better solution.

But to each their own!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic