You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "Clinton Begin (JIRA)" <ib...@incubator.apache.org> on 2005/02/01 18:35:22 UTC

[jira] Commented: (IBATIS-63) Add nullValue setting to SQL map description file.

     [ 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