Ronald, first of all, 0.9.6 has been regression tested for about three months before having been released back in February. As far as your problem is concerned, could you create a bug report (as outlined in the bug report guidelines), and we'll take care of your problem (if it turns out to be a genuine problem).
As to your problem, can you please show us the mapping file for 'ObjectName' ? Regards Werner wg> -----Original Message----- wg> From: Ronald Rudy [mailto:[EMAIL PROTECTED] wg> Sent: Friday, June 03, 2005 1:30 PM wg> To: dev@castor.codehaus.org wg> Subject: [castor-dev] Strange Issue on OQL Query wg> wg> wg> I'm running Castor 0.9.4.3 . Moving to 0.9.6 caused some wg> minor issues, and wg> I've not the time to drop the latest Castor in and do full wg> regression wg> testing. wg> wg> I have an issue where if I do a select with little or no wg> parameters I get wg> very strange results. wg> wg> First of all, there are only 29 records total for the table wg> I'm pulling wg> from. If I do a straight select (using OQL, e.g. "SELECT o FROM wg> ObjectName") I get not 29, but 30 records. The first wg> record is being placed wg> as the 30th and final record. wg> wg> If I place a WHERE clause on my OQL, which should take away wg> one of the 29 wg> records leaving 28, I still have 30 records being pulled wg> from my OQL Query. wg> wg> Stranger still, if I place an ORDER BY on a string field to wg> alphabetize the wg> resultset, it pulls not 28, 29, or 30, but 34. There wg> doesn't seem to be any wg> sort of pattern to this particular set. For reference, not wg> that it will wg> help, here are the primary keys of the set of 34: wg> wg> 1: 930016 wg> 2: 1961509 wg> 3: 589902 wg> 4: 593437 wg> 5: 586982 wg> 6: 584062 wg> 7: 5002 wg> 8: 85 wg> 9: 84 wg> 10: 99081 wg> 11: 83 wg> 12: 99081 <-- repeat of 10th wg> 13: 83 <-- repeat of 11th wg> 14: 81 wg> 15: 501478 wg> 16: 81 <-- repeat of 14th wg> 17: 87 wg> 18: 325893 wg> 19: 87 <-- repeat of 17th wg> 20: 86 wg> 21: 1064890 wg> 22: 487895 wg> 23: 490621 wg> 24: 487895 <-- repeat of 22nd wg> 25: 863602 wg> 26: 919613 wg> 27: 80 wg> 28: 544421 wg> 29: 781975 wg> 30: 796335 wg> 31: 781975 <-- repeat of 29 wg> 32: 785875 wg> 33: 532108 wg> 34: 535028 wg> wg> wg> After tracking this down, it appears to be caused by a wg> "many-key" type wg> mapping, which in this case is a map to a linking table with another wg> table/object to make a many-to-many type relationship. wg> Removing this fixes wg> the above query, but it then requires that this wg> many-to-many relationship be wg> handled manually. wg> wg> Is there any known resolution for this issue? wg> wg> -Ron wg> wg> wg> ------------------------------------------------- wg> If you wish to unsubscribe from this list, please wg> send an empty message to the following address: wg> wg> [EMAIL PROTECTED] wg> ------------------------------------------------- wg> wg> ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
