Hi Chris, Nick, sorry for coming back to you so late, but I have been trying to make up for a short summer here in Austria by taking a week off and spending some time at the Turkish Rivera .. ;-).
Having said that, I'd like to gain a more complete understanding of your issue. It looks like Castor fails to load children of a 1:M relation where you are effectively using polymorphism for this relation, correct ? I know that it seems quite difficult for you to provide us with something replayable, but can you at least provide me with the *minimal* mapping file fragments to understand the ArrayIndexOutOfBoundExceptions: 15 In other words, what class is being loaded, how many fields is it meant to have (as declared in the mapping file), etc ? Without any of this, this is going to be hard. Regards Werner On Wed, 5 Oct 2005 08:23:44 -0400, Nick Stuart wrote: >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] >------------------------------------------------- > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
