ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Commented: (IBATIS-63) Add nullValue setting to SQL map description file.
Date Tue, 01 Feb 2005 17:35:22 GMT
     [ 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


Mime
View raw message