You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Bing Zou <xi...@gmail.com> on 2005/01/28 21:10:19 UTC
A question about nullValue in resultMap.
Hi,
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.
Thanks a lot.
Bing
Re: A question about nullValue in resultMap.
Posted by Clinton Begin <cl...@gmail.com>.
I agree with Larry 100% on this one. Implicit behaviour is the enemy
of maintainable software.
Clinton
On Wed, 2 Feb 2005 06:17:21 -0700, Larry Meadors
<la...@gmail.com> wrote:
> On Wed, 02 Feb 2005 13:07:43 +1100, Huy <hu...@swiftdsl.com.au> wrote:
> > Larry Meadors wrote:
> > > Just curious: If you can have null values, why are you using primitive
> > > values.
> >
> > Well primitives are easier to work with in Java IMO.
>
> Not if you need null support. :-)
>
> Which do you need more? Null support or ease of use? You do not get
> both, and not even the autoboxing in jdk5 will fix that.
>
> > > You do realize that even if we do not call the setter, the
> > > property holder will be set to 0 anyway, right?
> >
> > Which I guess is the point, so why do we have to specify this in sqlmap.
>
> So we do not have to force that decision upon other users of the framework.
>
> IMO, this is not what I would expect from the tool. If there is a null
> in a field that cannot accurately represent null values, I want an
> error. I want a big, nasty error that makes the lights in the server
> room flicker, and sets off alarms. The *last* thing I want is for my
> framework to assume that it is supposed to be zero, and just happily
> chug along.
>
> Larry
>
Re: A question about nullValue in resultMap.
Posted by Huy <hu...@swiftdsl.com.au>.
Clinton Begin wrote:
>>I've never liked to use Integer. Is it really the
>>better design choice ? and why ? Is it the
>
>
> Not for all situations. But the simple fact is that a primitive
> cannot represent NULL state without using a "magic number". Magic
> numbers are (to the best of my experience and education) NEVER a good
> idea. Hence, you're better off with an Integer than a "magic int".
I have to admit I was always of the opposite view. I hated nulls with a
vengeance when it came to database data. I also don't like magic numbers
unless they had meaning in the given domain. Most of the time (95%) zero
made perfect senses hence I always defaulted my database columns to zero
(never -1 or anything like that). In cases where I needed to know the
difference between zero and null (which was rare) there were always
other ways to represent this (eg. existence of a row etc.)
>>From a practical perspective, Integers are better because they are
> objects and can take part in Object features. For example, you can
> use them in a collection or pass them as a parameter to your SQL Maps.
> If you're lucky enough to use J2SE 5, then this is less
> important...but trust me, primitives are no less of a problem in J2SE
> 5.
This is a major problem I found with java; i.e not being able to use
primitives in collections. I think either primitives is a real wart in
java or collections is missing a real feature. That reminds me of a
little annoyance with sqlmap where I always had to wrap my primitives in
Integer, Boolean etc when passing it to the query, update methods.
>>From a purely academic sense, Java is a hybrid language. A Smalltalk
> developer would tell you to avoid primitives like the plague. A C
> developer, would tell you primitives are the only way to go.
> Generally speaking, Java is more OO than not, so the Smalltalk
> developer would probably be correct more often than the C developer.
>
> All I can say is...dude, you'd love Ruby. ;-)
I'm actually a python fan and i'm sure you know about the rivalry there
;-) There are some nice features in ruby though. But I think that
activerecord (ruby on rails) thing they have doesn't come close to
sqlmaps for major applications.
Regards,
Huy
Re: A question about nullValue in resultMap.
Posted by friendVU admin <ma...@friendvu.com>.
Clinton Begin wrote:
>
>>From a purely academic sense, Java is a hybrid language. A Smalltalk
>developer would tell you to avoid primitives like the plague. A C
>developer, would tell you primitives are the only way to go.
>Generally speaking, Java is more OO than not, so the Smalltalk
>developer would probably be correct more often than the C developer.
>
>All I can say is...dude, you'd love Ruby. ;-)
>
>
>
Or Groovy! (and ... I think one can rig SQL maps w/ Groovy.
.V
Re: A question about nullValue in resultMap.
Posted by Clinton Begin <cl...@gmail.com>.
> I've never liked to use Integer. Is it really the
> better design choice ? and why ? Is it the
Not for all situations. But the simple fact is that a primitive
cannot represent NULL state without using a "magic number". Magic
numbers are (to the best of my experience and education) NEVER a good
idea. Hence, you're better off with an Integer than a "magic int".
Re: A question about nullValue in resultMap.
Posted by Huy <hu...@swiftdsl.com.au>.
Clinton Begin wrote:
> You guys have to understand that this is a tough call for us. It's
> just such a horrible implicit behaviour that I can't even imagine the
> concequences of it.
> This falls into the category of: "Feature to support bad design choices."
>
> Regardless of whether you have control over the database or not, you
> seem to have control over two other things:
>
> 1) The JavaBean design - You can solve the problem by using Integer
> instead of int (a good design choice).
I'm going a bit OT here, but I'm really interested in this point. I'm
not exactly a very experienced java programmer but I've never liked to
use Integer. Is it really the better design choice ? and why ? Is it the
null thing or is because it makes everything more consistent in terms of
being objects.
> - OR -
>
> 2) The SQL Maps - You can solve the problem by specifying nullValue
> attribute of the result mapping (an explicit behaviour and a good
> design choice).
I guess explicit is always better, but I'm a lazy programmer sometimes
;-) that's one of the reasons why i use SQL Maps, it does so much for me
automatically (if not automagically).
Regards,
Huy
Re: A question about nullValue in resultMap.
Posted by Clinton Begin <cl...@gmail.com>.
You guys have to understand that this is a tough call for us. It's
just such a horrible implicit behaviour that I can't even imagine the
concequences of it.
This falls into the category of: "Feature to support bad design choices."
Regardless of whether you have control over the database or not, you
seem to have control over two other things:
1) The JavaBean design - You can solve the problem by using Integer
instead of int (a good design choice).
- OR -
2) The SQL Maps - You can solve the problem by specifying nullValue
attribute of the result mapping (an explicit behaviour and a good
design choice).
Admittedly, both are more work that what you propose. However, the
simple solution is not always the best solution.
Cheers,
Clinton
At the end of the day the prop
On Fri, 4 Feb 2005 15:23:31 -0500, Bing Zou <xi...@gmail.com> wrote:
> Yes, that's exactly what we want. :-P
> Maybe you could add your comments here:
> http://issues.apache.org/jira/browse/IBATIS-63
>
> Thanks.
> Bing
>
> On Thu, 03 Feb 2005 23:51:43 +1100, Huy <hu...@swiftdsl.com.au> wrote:
> > Larry Meadors wrote:
> > > On Wed, 02 Feb 2005 13:07:43 +1100, Huy <hu...@swiftdsl.com.au> wrote:
> > >
> > >>Larry Meadors wrote:
> > >>
> > >>>Just curious: If you can have null values, why are you using primitive
> > >>>values.
> > >>
> > >>Well primitives are easier to work with in Java IMO.
> > >
> > >
> > > Not if you need null support. :-)
> > >
> > > Which do you need more? Null support or ease of use? You do not get
> > > both, and not even the autoboxing in jdk5 will fix that.
> >
> > I see your point, but sometimes we can't control databases designed 20
> > years ago which allowed nulls in integer columns when such a thing was
> > not desirable. I guess it's not a major issue, just something a bit
> > different that we have to worry about when dealing with primitives.
> > Maybe there can be some global configuration to not assign nulls to
> > primitive properties so that we can default these in our beans. We have
> > to default them anyway to something in the beans so why do we have to do
> > it in two places. Of course then we'd need something to specify when
> > nulls are not wanted on certain columns. Ahhh....sounds like I'm going
> > in circles.
> >
> > >>>You do realize that even if we do not call the setter, the
> > >>>property holder will be set to 0 anyway, right?
> > >>
> > >>Which I guess is the point, so why do we have to specify this in sqlmap.
> > >
> > >
> > > So we do not have to force that decision upon other users of the framework.
> > >
> > > IMO, this is not what I would expect from the tool. If there is a null
> > > in a field that cannot accurately represent null values, I want an
> > > error. I want a big, nasty error that makes the lights in the server
> > > room flicker, and sets off alarms. The *last* thing I want is for my
> > > framework to assume that it is supposed to be zero, and just happily
> > > chug along.
> >
> > Fair enough, but nulls in number columns always has caused me more
> > problems then zeros in number columns.
> >
> > Huy
> >
>
Re: A question about nullValue in resultMap.
Posted by Bing Zou <xi...@gmail.com>.
Yes, that's exactly what we want. :-P
Maybe you could add your comments here:
http://issues.apache.org/jira/browse/IBATIS-63
Thanks.
Bing
On Thu, 03 Feb 2005 23:51:43 +1100, Huy <hu...@swiftdsl.com.au> wrote:
> Larry Meadors wrote:
> > On Wed, 02 Feb 2005 13:07:43 +1100, Huy <hu...@swiftdsl.com.au> wrote:
> >
> >>Larry Meadors wrote:
> >>
> >>>Just curious: If you can have null values, why are you using primitive
> >>>values.
> >>
> >>Well primitives are easier to work with in Java IMO.
> >
> >
> > Not if you need null support. :-)
> >
> > Which do you need more? Null support or ease of use? You do not get
> > both, and not even the autoboxing in jdk5 will fix that.
>
> I see your point, but sometimes we can't control databases designed 20
> years ago which allowed nulls in integer columns when such a thing was
> not desirable. I guess it's not a major issue, just something a bit
> different that we have to worry about when dealing with primitives.
> Maybe there can be some global configuration to not assign nulls to
> primitive properties so that we can default these in our beans. We have
> to default them anyway to something in the beans so why do we have to do
> it in two places. Of course then we'd need something to specify when
> nulls are not wanted on certain columns. Ahhh....sounds like I'm going
> in circles.
>
> >>>You do realize that even if we do not call the setter, the
> >>>property holder will be set to 0 anyway, right?
> >>
> >>Which I guess is the point, so why do we have to specify this in sqlmap.
> >
> >
> > So we do not have to force that decision upon other users of the framework.
> >
> > IMO, this is not what I would expect from the tool. If there is a null
> > in a field that cannot accurately represent null values, I want an
> > error. I want a big, nasty error that makes the lights in the server
> > room flicker, and sets off alarms. The *last* thing I want is for my
> > framework to assume that it is supposed to be zero, and just happily
> > chug along.
>
> Fair enough, but nulls in number columns always has caused me more
> problems then zeros in number columns.
>
> Huy
>
Re: A question about nullValue in resultMap.
Posted by Huy <hu...@swiftdsl.com.au>.
Larry Meadors wrote:
> On Wed, 02 Feb 2005 13:07:43 +1100, Huy <hu...@swiftdsl.com.au> wrote:
>
>>Larry Meadors wrote:
>>
>>>Just curious: If you can have null values, why are you using primitive
>>>values.
>>
>>Well primitives are easier to work with in Java IMO.
>
>
> Not if you need null support. :-)
>
> Which do you need more? Null support or ease of use? You do not get
> both, and not even the autoboxing in jdk5 will fix that.
I see your point, but sometimes we can't control databases designed 20
years ago which allowed nulls in integer columns when such a thing was
not desirable. I guess it's not a major issue, just something a bit
different that we have to worry about when dealing with primitives.
Maybe there can be some global configuration to not assign nulls to
primitive properties so that we can default these in our beans. We have
to default them anyway to something in the beans so why do we have to do
it in two places. Of course then we'd need something to specify when
nulls are not wanted on certain columns. Ahhh....sounds like I'm going
in circles.
>>>You do realize that even if we do not call the setter, the
>>>property holder will be set to 0 anyway, right?
>>
>>Which I guess is the point, so why do we have to specify this in sqlmap.
>
>
> So we do not have to force that decision upon other users of the framework.
>
> IMO, this is not what I would expect from the tool. If there is a null
> in a field that cannot accurately represent null values, I want an
> error. I want a big, nasty error that makes the lights in the server
> room flicker, and sets off alarms. The *last* thing I want is for my
> framework to assume that it is supposed to be zero, and just happily
> chug along.
Fair enough, but nulls in number columns always has caused me more
problems then zeros in number columns.
Huy
Re: A question about nullValue in resultMap.
Posted by Larry Meadors <la...@gmail.com>.
On Wed, 02 Feb 2005 13:07:43 +1100, Huy <hu...@swiftdsl.com.au> wrote:
> Larry Meadors wrote:
> > Just curious: If you can have null values, why are you using primitive
> > values.
>
> Well primitives are easier to work with in Java IMO.
Not if you need null support. :-)
Which do you need more? Null support or ease of use? You do not get
both, and not even the autoboxing in jdk5 will fix that.
> > You do realize that even if we do not call the setter, the
> > property holder will be set to 0 anyway, right?
>
> Which I guess is the point, so why do we have to specify this in sqlmap.
So we do not have to force that decision upon other users of the framework.
IMO, this is not what I would expect from the tool. If there is a null
in a field that cannot accurately represent null values, I want an
error. I want a big, nasty error that makes the lights in the server
room flicker, and sets off alarms. The *last* thing I want is for my
framework to assume that it is supposed to be zero, and just happily
chug along.
Larry
Re: A question about nullValue in resultMap.
Posted by Huy <hu...@swiftdsl.com.au>.
Larry Meadors wrote:
> Just curious: If you can have null values, why are you using primitive
> values.
Well primitives are easier to work with in Java IMO.
> You do realize that even if we do not call the setter, the
> property holder will be set to 0 anyway, right?
Which I guess is the point, so why do we have to specify this in sqlmap.
Regards,
Huy
Re: A question about nullValue in resultMap.
Posted by Larry Meadors <la...@gmail.com>.
Just curious: If you can have null values, why are you using primitive
values. You do realize that even if we do not call the setter, the
property holder will be set to 0 anyway, right?
public class MyBean{
int myProp; // <-- since this MUST be initialized, the JVM sets it to 0
public int getMyProp(){
return myProp;
}
public void setMyProp(int val){
myProp = val;
}
public static void main(String[] a){
MyBean myBean = new MyBean();
System.out.println(myBean.getMyProp()); // <-- will be 0
}
}
So, do you have some other logig in your setter or something that
detects if it was called, or is there some other compelling reason for
this? IMO, it seems silly.
Larry
On Fri, 28 Jan 2005 15:10:19 -0500, Bing Zou <xi...@gmail.com> wrote:
> Hi,
>
> 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.
>
> Thanks a lot.
> Bing
>