Auto-provision of jdbcType for "nullable parameters" case

[Nate Weiss <na...@twintechs.com>]

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

Re: Auto-provision of jdbcType for "nullable parameters" case

[Nate Weiss <na...@twintechs.com>]

On 4/9/2010 8:22 PM, Clinton Begin wrote:
> 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

Wow, thank you, I just tested it out and it seems to be working 
perfectly so far.  I was able to remove the jdbcType meta-info from my 
#{} parameter notation and it worked.  I will let you know if I run into 
any problems with it, as I'll be doing some more of this over the coming 
days.

By the way, if I'm not mistaken, I believe that opening a session with 
ExecutorType.BATCH is incompatible with useGeneratedKeys="true".  This 
makes conceptual sense I suppose and probably warrants a bit of a "duh" 
on my part, as I imagine the driver may not be capable of back the keys 
correctly when batching is in effect since there could be more than one 
(I assume).  If this is the case a quick note in the doc might be 
helpful in the form of a note (I could jot something down and submit) or 
in the error message that reads "Error getting generated key or setting 
result to parameter object"... maybe adding something like "Note: If you 
are using the batched executor this would be expected behavior, please 
use a different executor" would be nice.

In any case thank you very much for that fixed build, really appreciate it.

nate

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

Re: Auto-provision of jdbcType for "nullable parameters" case

[Clinton Begin <cl...@gmail.com>]

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 <na...@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
>
>