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-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
