Thinking about this more, my opinion is that you should use an Integer
(vs. int) type so that you can properly represent null values.  This
eliminates the problem and is a more "true" design, free of magic
numbers.

nullValue was intended for people who don't have a choice (i.e. legacy
code).  It sounds like each of you might have a choice in your cases.

Cheers,
Clinton


On Tue, 22 Mar 2005 10:26:17 -0600, Karen Koch <[EMAIL PROTECTED]> wrote:
>  An idea... If we could indicate in the resultMap one non-nullable database
> columns (like a primary key, something unlikely to become NULLable with a
> later iteration of the database design), we'd know that if a NULL was read
> out of the query for that field, that no record existed...
> 
> -----Original Message-----
> From: Karen Koch [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 22, 2005 10:10 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Modeling 1:N where N=0
> 
> Absolutely.  I'll do that as soon as I figure out how to post a request in
> JIRA.  :-)
> 
> Yeah, I see what you are saying... It's difficult to distinguish between
> whether a record exists with all null values or no record exists...
> Although, if a record exists with ALL null values, I'm having a hard time
> (with the application experience I have) coming up with a reason the record
> would exist at all... Could iBATIS simply check for that condition before
> performing the null value substitutions and skip the null value
> substitutions in that case?
> 
> Any idea of the priority such an issue will get?
> 
> Thanks!
> Karen
> 
> -----Original Message-----
> From: Clinton Begin [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 22, 2005 10:03 AM
> To: Karen Koch
> Subject: Re: Modeling 1:N where N=0
> 
> No, actually that makes sense now.....
> 
> I'm not sure what makes sense semantically.  In effect, you are receiving
> tabluar data and have specified that for a certain column NULL ==
> <something>.
> 
> I don't think this behaviour will be changed....at the very least it will
> take some thought.
> 
> Could you post a feature request in JIRA for this?
> 
> Cheers,
> Clinton
> 
> On Tue, 22 Mar 2005 08:26:53 -0600, Karen Koch <[EMAIL PROTECTED]> wrote:
> > I haven't stepped through the Ibatis source, so it's difficult for me
> > to say exactly what is happening within Ibatis code.  However, from an
> > Ibatis user
> > perspective:
> >
> > One resultMap has a List property in it.  The List property has a
> > resultMap indicated.  The resultMap of the child object (List
> > property) has nullValue=<somevalue> specified for one or more
> > properties.  A query written with a LEFT JOIN returns one parent
> > record but no child records.  One would expect that one parent object
> > would be created, but that the list property would remain as an empty
> > list (no child objects created).  It *seems* that due to the
> > nullValue=<somevalue> specifiers, one child object is being created
> anyhow.
> >
> > I would happily step through the Ibatis source to dig deeper if you
> > can tell me what I need to do to set that up in NetBeans 4.0.  Thanks
> > in advance for any help you can offer.
> >
> > Karen
> > -----Original Message-----
> > From: Clinton Begin [mailto:[EMAIL PROTECTED]
> > Sent: Monday, March 21, 2005 10:22 PM
> > To: Karen Koch
> > Subject: Re: Modeling 1:N where N=0
> >
> > The null values that are checked are in an Object[] array type.  So it
> > shouldn't matter if it's a primitive.
> >
> > Could someone help me understand the problem better?
> >
> > Cheers,
> > Clinton
> >
> > On Mon, 21 Mar 2005 21:13:40 -0600, Karen Koch <[EMAIL PROTECTED]>
> wrote:
> > > Scott/Clinton --
> > >
> > > I am now experiencing this same issue.  Is there a recommended
> > > official solution?  If not, Scott, did you come up with a good
> workaround?
> > >
> > > Thank you!
> > >
> > > Karen Koch
> > >
> > > -----Original Message-----
> > > From: Scott Zhu [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, March 09, 2005 4:44 PM
> > > To: Karen Koch
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Modeling 1:N where N=0
> > >
> > > Thanks Karen. In my case, I don't have that issue. But because I set
> > > a nullValue attribute, I saw a (bogus) object is being created. It
> > > contains the defaul value for the int member and other null values.
> > > But if I don't set the nullValue attribute, I'd get
> NullPointerException.
> > >
> > > On Wed, 9 Mar 2005 16:28:49 -0600, Karen Koch <[EMAIL PROTECTED]> wrote:
> > > > I don't know if this will help at all, Scott, but the problem for
> > > > me was that I had a foreign key reference in my child table that
> > > > related to the primary key of the parent table -- and the column
> > > > was named
> > > "TimesheetKey"
> > > > in each table.  The resultset that I was returning from the query
> > > > was binding the TimesheetKey field value from the parent table
> > > > into the child object as well as the parent object, which caused a
> > > > child object to be created.
> > > >
> > > > I worked around this by qualifying the column name with the table
> > > > name in the resultset and aliasing the column returned from the
> > > > child table in my statement and associated resultMap.
> > > >
> > > > I realize this doesn't really address your question, but I thought
> > > > I'd respond just in case it was helpful.  Feel free to ignore this
> > entirely...
> > > >
> > > > Karen
> > > >
> > > > -----Original Message-----
> > > > From: Scott Zhu [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, March 09, 2005 4:15 PM
> > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > > Subject: Re: Modeling 1:N where N=0
> > > >
> > > > I came across the same issue too. I understand that I need to have
> > > > the resultMap contains all null values so the child object will
> > > > not get generated. But I have a "int" type member in that object,
> > > > isn't that true we always need a "nullValue" in the sqlMap so we
> > > > don't get a NullPointerException (if the value is allowed to be null
> in the db)?
> > > > then once I do that, the resultMap would always contains some
> > > > non-null data. What did I miss here? Thanks
> > > >
> > > > -Scott
> > > >
> > > > >iBATIS will populate child objects if there is ANY non-null data
> > > > >mapped to the child in the result map.  If you don't want iBATIS
> > > > >to create the child, make sure it's mapped to null data...there's
> > > > >really no reason why you shouldn't be able to achieve this.
> > > > >
> > > > >Cheers,
> > > > >Clinton
> > > >
> > > >
> > >
> > >
> >
> >
> 
>

Reply via email to