Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When accessing ResultSets in JDBC, is there an elegant way to distinguish between nulls and actual zero values?

When using JDBC and accessing primitive types via a result set, is there a more elegant way to deal with the null/0 than the following:

int myInt = rs.getInt(columnNumber)
if(rs.wasNull())?
{
 // Treat as null
} else
{
 // Treat as 0
}

I personally cringe whenever I see this sort of code. I fail to see why ResultSet was not defined to return the boxed integer types (except, perhaps, performance) or at least provide both. Bonus points if anyone can convince me that the current API design is great :)

My personal solution was to write a wrapper that returns an Integer (I care more about elegance of client code than performance), but I'm wondering if I'm missing a better way to do this.

Just to clarify, what bothers me about this code is not the length, but the fact that a it creates a state dependency between subsequent calls, and what appears like a simple getter actually has a side effect within the same row.

like image 344
Uri Avatar asked May 05 '10 22:05

Uri


1 Answers

The JDBC API was designed for performance. Remember that it dates back to Java 1.1, when a large turnover of objects was a JVM killer (it wasn't until the Hotspot JVMs in Java 1.2+ that you could relax this kind of limitation). Using boxed types would have ruined the performance of high volume applications at the time.

Now, it can't be changed because of backwards compatibility. So no, it's not ideal any more, but it's a pretty minor thing to workaround.

If you want to avoid the type of code you mentioned, you can always use getObject() instead of getInt(), which will return an object of one of the subtypes of java.lang.Number, probably Integer or BigInteger, depending on the specific SQL type.

like image 104
skaffman Avatar answered Oct 30 '22 14:10

skaffman