ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate Weiss <n...@twintechs.com>
Subject Auto-provision of jdbcType for "nullable parameters" case
Date Sat, 10 Apr 2010 00:18:49 GMT
Hi--

First, really enjoying iBatis 3.  Thanks to all who have obviously 
thought and worked hard on this lovely framework.  I am using it in 
combination with Guice 2.0 at the moment and enjoying it.

The only item that is a bit of a nuisance for me right now are 
situations that result in "JDBC requires that the JdbcType must be 
specified for all nullable parameters".  Sometimes NULL values are 
desirable or needed in practice, and it's a bit of a bummer for any 
nullable column to be kind of relegated to a second-class citizen in 
terms of simplicity and conciseness in mapper files/classes.

At first read of the documentation I thought that I would only need to 
provide the jdbcType when I provided a null value *and* the java type 
was unknown to iBatis.  This was not the fault of the documentation, 
just optimistic reading on my part.  :)

That said, and without having investigated the source (though I would be 
willing for sure) it does seem confusing to me that iBatis is not able 
to provide the jdbcType for me in situations when I am passing a Bean or 
POJO as my parameter.

I read the linked doc about PreparedStatement.setNull() and so I do 
understand why iBatis needs the jdbcType.  It just seems to me that this 
information would be available to iBatis at this point via reflection of 
the Bean/POJO.  I guess in my mind I am assuming that this sort of 
reflection is already going on anyway at this point; but maybe not, 
maybe the type detection is strictly by value rather than via reflection?

As currently implemented, as a practical matter you likely have to 
provide the jdbcType for any column that accepts nulls in the DB, which 
is a bit time consuming and (IMO) undermines the brevity and elegance of 
the mappers.  One *could* choose to provide the jdbcType only for those 
nullable columns that will actually get assigned a null at runtime, but 
that requires more foresight than may be possible at the time... and 
becomes one more thing to forget about and thus introduce application 
bugs down the line.

Does anyone know if what I'm wishing for is fundamentally impossible for 
some reason, or perhaps was just considered too complicated or costly to 
implement at this time?

I'm not expecting anyone to jump up and do a bunch of work for me of 
course (I'm standing on shoulders as it is).  Perhaps an implementation 
of something reflection based for these cases is something I could 
contribute, if anyone felt it was fundamentally feasible and desirable. 
So as not to introduce undesired runtime cost, I suppose there could be 
a switch at the insert/select/update/etc level that said whether to use 
reflection

Of course, I may be missing the point somewhere, been known to happen.

Thanks again,
nate



---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org


Mime
View raw message