[
http://issues.apache.org/jira/browse/IBATIS-63?page=comments#action_58419 ]
Clinton Begin commented on IBATIS-63:
-------------------------------------
I have to disagree. Option #1 of changing your primitive types to use the
object wrapper types is the BEST solution in my opinion. It's a much better
design choice than using a "magic number" to represent null state.
Since there's already at least 3 acceptable ways to solve this problem, I'm not
expecting they'll be a lot of support, especially considering the confusion
such a property will cause on the code side ("why isn't such-and-such property
being set?"
I agree that <resultMap> elements are a bit verbose, which is why I'm proposing
an inline resultMap specification. Something similar to inline parameter maps,
but with a different token. For example:
SELECT
%someColumn,nullValue=blah%
...
I haven't totally decided on the syntax yet. But what would you think of that
in terms of simplifying your SQL map files, while maintaining a good design.
Cheers,
Clinton
> Add nullValue setting to SQL map description file.
> --------------------------------------------------
>
> Key: IBATIS-63
> URL: http://issues.apache.org/jira/browse/IBATIS-63
> Project: iBatis for Java
> Type: Improvement
> Components: SQL Maps
> Environment: All.
> Reporter: Bing Zou
>
> So far in iBbatis, when the parameter of the result Bean's setter is
> primitive type (for example, setParentCategoryID(long id)), if the
> corresponding column might get a database NULL value during execution, we
> have at least three solutions:
> 1. Change the Bean's setter to use Object type parameter instead of primitive
> type. (for example, use setParentCategoryID(Long id_object) instead).
> 2. Use ResultMap and specify nullValue of the nullable property.
> 3. Use ResultMap and specify TypeHandler to take care of the returned Null
> value.
> Obviously solution 1 is not a good one while solution 2 and 3 require using
> ResultMap instead of using ResultClass directly.
> Now the question is, I want to keep the sqlmap xml file as simple as
> possible, so I want to use as much implicit result mapping as possible.
> (Because using resultMap will make the xml file a little bit harder to read,
> understand, debug and maintain.) I want to avoid ResultMap even there is
> nullable column in the SQL statement. So I hope iBatis could take care of the
> null values for me.
> I am wondering whether the iBatis team will consider adding one more property
> to the iBatis configuration file like SkipSettingNullResult. If
> SkipSettingNullResult=true, while iBatis sees a Null value returned
> from the resultSet, if the corresponding setter is taking a primitive type
> parameter, iBatis simply skip this setter and the Bean will use the default
> value instead of executing the setter.
> I will sincerely appreciate it if the iBatis team could make it happen in the
> near future.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
