aspose file tools*
The moose likes JDBC and the fly likes retrieving null values from ResultSet Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "retrieving null values from ResultSet" Watch "retrieving null values from ResultSet" New topic
Author

retrieving null values from ResultSet

Dan Murphy
Ranch Hand

Joined: Mar 29, 2005
Posts: 126
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


SCJP, SCJD, SCWCD
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

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.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Dan Murphy
Ranch Hand

Joined: Mar 29, 2005
Posts: 126
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
internet detective
Marshal

Joined: May 26, 2003
Posts: 29241
    
139

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Dan Murphy
Ranch Hand

Joined: Mar 29, 2005
Posts: 126

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
internet detective
Marshal

Joined: May 26, 2003
Posts: 29241
    
139

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

Joined: Mar 22, 2008
Posts: 265

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!


There will always be people who are ahead of the curve, and people who are behind the curve. But knowledge moves the curve. --Bill James
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: retrieving null values from ResultSet
 
Similar Threads
JavaMail - Delivery failure
null vs. "" as a member of an array...
Message Dialog box --> action performed.
Problem with equals on collection
how can i insert a null value in a table