Thanks for the information! Very helpful. I think I will look at number two as well.
While I agree with the RedFlag, I only added those calls in the Ibatis implementation of the object. The API uses a wrapper that only allows the user to manipulate objects in an safe manner.
Funny thing is that when I set it up to do the N+1 select queries, it actuallly does what I expect. It was inconsistent and perhaps that was more concerning to me....
Thanks again!
Larry Meadors <[EMAIL PROTECTED]> wrote:
Larry Meadors <[EMAIL PROTECTED]> wrote:
I see - it sets the list empty, then populates it, but you are relying
on the setter to be supplied a full list because it processes the list
and manipulates the object at that point.
Editorial comment: Having get/set methods do processing is always
risky, and should ALWAYS be avoided if the property is not immutable
(as in this case). If it were a String, it would be a different story,
but in this case the set object can change after being set...red flag!
I see at least two options:
1) lazily do the manipulation when you try to get the Map from the parent
2) use a row handler and do it yourself - more code, similar performance
3) create your own List implementation, and do processing when items
are added/removed
Solution #1 is not much better, because the list is still mutable and
publicly accessible exposed. Without a custom List implementation, you
cannot expose the list in a read/write manner and not have this
problem.
I lean towards option #2 - I think it's simpler. I would even go a
step further and REMOVE the get/set methods for the List, and use
add/remove methods to add / remove children, and expose an interator
for users to get to the items. The reason is: How do you know that
someone else using the bean won't repeat what iBATIS does in 2-3
years? You do not - you have to code this more safely.
Solution #3 is most likely overkill, but could be made to work...I'd
still go towards #2.
Larry
On 9/15/05, Mukul Goyal <[EMAIL PROTECTED]>wrote:
> Thanks for the reply. So the details are that I am creating a resultMap with
> a groupBy clause:
>
>
>
>> />
>
>
>
> ..
>
>
>
> As I am stepping through the code, the RuleDetail object gets constructed
> and so do the RuleConstraint objects, as there is a 1:M relationship between
> RuleDetail and RuleConstraint. I put a breakpoint in the setRuleConstraints
> method of the RuleDetail. I notice that the List that gets passed in is
> always empty even though the RuleConstraint objects get constructed.
> Internally in the setRuleConstraints I am doing the following in pseudo
> code:
>
> class RuleDetail{
> private HashMap constraintMap;
>
> setRuleConstraints(List constraints){
> For each item in constraints, put into the constraintMap;
> }
> }
>
> But, I notice that the List is always empty. So I cr eated a temporary List
> that saves a reference to the List that is passed in by the
> setRuleConstraints. Even though it is initially empty when passed into the
> method, after the queryForObject returns, the List has values in it. So
> internally Ibatis must be populating the List AFTER it sets the List on the
> RuleDetail, instead of before.
>
> Does that make more sense?
>
> -Mukul
>
> Brandon Goodin <[EMAIL PROTECTED]>wrote:
> If you could provide more information about where this behavior is in
> iBatis as well as the code you are using to call it, that'd help us to
> see better what you are talking about.
>
> Thanks
> Brandon
>
> On 9/14/05, Mukul Goyal wrote:
> > I noticed that it is required (only when you are using the N+1 solution)
> for
> > an Object that contain other objects (1:M relationships) to have BOTH a
> & gt; getter and setter method. At first I didn't realize why this was required,
> > but as I was debugging a problem I realized why.
> >
> > If the getter returns NULL during object population, IBATIS constructs a
> new
> > List object and calls the setter on the parent object. However, when the
> > setter is called the List is empty. The IBATIS implementation banks on the
> > fact that you are maintaining the object inside of your bean. After it
> calls
> > the setter with the empty List, it then goes and populates the List. I put
> a
> > break point in my settter method and realized that the size of the list is
> > never greater than 0. This seems problematic because internally I do not
> > represent the content of the data as a list.
> >
> > Is this by design or is there a work around to this problem?
> >
> > Thanks,
> > ; Mukul
> >
> >
> > ________________________________
> > Yahoo! for Good
> > Click here to donate to the Hurricane Katrina relief effort.
> >
> >
>
>
> ________________________________
> Yahoo! for Good
> Click here to donate to the Hurricane Katrina relief effort.
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
