ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: A question about nullValue in resultMap.
Date Fri, 04 Feb 2005 20:42:17 GMT
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 <xiguamaillist@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 <huymail@swiftdsl.com.au> wrote:
> > Larry Meadors wrote:
> > > On Wed, 02 Feb 2005 13:07:43 +1100, Huy <huymail@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
> >
>

Mime
View raw message