ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Auto-provision of jdbcType for "nullable parameters" case
Date Sat, 10 Apr 2010 00:22:25 GMT
I've improved this in the next release.  While it's not officially released
yet, try this:



On Fri, Apr 9, 2010 at 6:18 PM, Nate Weiss <nate@twintechs.com> wrote:

> 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

View raw message