Yep, this sounds very familiar to a problem I was having when trying out the new poly stuff. Supposedly Werners patch for 1195 should of helped to take care of this issue, becuase it sounds almost the same.
One thing you could do is look over that bug at http://jira.codehaus.org/browse/CASTOR-1195 and see if it matches, and if so, make sure you are using the latest release and see if you can reproduce the problem in small case. If so either reopen the bug or make a new one pointing out this one. I'm pretty sure we are running against the same problem, but I just want to make sure. I personally dont deal with the 'deepness' of the classes you have, but the child/parent relationships sound a lot a like. On 10/4/05, Chris Hoy Poy <[EMAIL PROTECTED]> wrote: > It seems to be when an extended "parent" class, has a number of 1-* > relationships (that can include extended classes). Where the problem is > really bad (ie it becomes consistently broken) is where our poly-maps are > over 10-12+ classes "deep", if you like. I don't think the depth has > anything to do with it, at least. > > The problem occurs when we try to load a list of the extended children (in > a number of cases we have defined the castor classes to be "one-way" - ie > we only define the relationship to castor in the child class). > ( ie we leave off the > <field name="dependent" type="test.DependentObj"> > <sql many-key="parentId"/> > </field> > > ) from the parent.. > > not sure if that makes a difference, but we have a need to grab individual > objects. We then use our own functions to grab the "child" or dependent > vectors, if we require them. (in particular, we use long transactions a > lot, mainly in read-only, but using the query.execute method, and one of > the firs t "classes" represents a client, which might have ~5-10,000 > dependent sites.., and having the class fetch the entire child list when > we just want the company name is slow.. particularly when some of those > sites can have up to 1000+ objects in dependent arrays as well.. > > its just lazy loading across long transactions as we see it ;) My > knowledge of castor internals is quite minimal, so I have no idea if thats > an issue or not, but it might well do so - it still seems to me that the > extended "parent" class is, sometimes, being mis-fetched as just the > superclass. > > -- > //chris > > <quote who="Nick Stuart"> > > My issue was 1195, however it appears to be closed, shame on me for > > not keeping up with it and checking to make sure everything worked. > > > > Anyways, whats the mapping look like for your poly classes? Can you > > tell if the problem is happening when you are trying to load the > > extended object? Or the class that holds the extended object? (if > > there is one) > > > > Some hints to the type of relationships (1-*, *-*, etc) would be > > helpful as well. > > > > And like I said, you should be able to stay with 0.9.9 if you revert > > back to your original code. All previous test cases passed with this > > new release so it "shouldn't" have borked any 0.9.7 code. > > > > -Nick > > > > > > > > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
