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 > > > > > > > > > > > > > > > > > > > >