I've improved this in the next release. While it's not officially released yet, try this:
http://people.apache.org/builds/ibatis/ibatis-3-core/ibatis-core-3.0.0-bundle.zip Clinton On Fri, Apr 9, 2010 at 6:18 PM, Nate Weiss <n...@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-unsubscr...@ibatis.apache.org > For additional commands, e-mail: user-java-h...@ibatis.apache.org > >
