Ronald, I think the problem might be related to the fact that you have an ObjectLink artefact around. If you happen to have a many-to-many relation between two entities A and B, you will not need a separate 'mapping' entity to express this relation. Iow, there's
a) an entity A, plus a table b) an entity B, plus a table c) a table that's used to store the entities related to each other. I thin it would be useful if you tried to modify your application in the sense that you try to drop ObjectLink. Let me know whether you need any further assistance. Werner wg> -----Original Message----- wg> From: Ronald Rudy [mailto:[EMAIL PROTECTED] wg> Sent: Friday, June 03, 2005 1:58 PM wg> To: dev@castor.codehaus.org wg> Subject: RE: [castor-dev] Strange Issue on OQL Query wg> wg> wg> I didn't intend to mean regression testing for Castor, I wg> meant for my wg> application. There wasn't an error in Castor 0.9.6, it was wg> an issue of wg> compatibility somewhere within my application that I didn't wg> have time to wg> address - sorry for the confusion. :) wg> wg> wg> Here's a mapping snippet: wg> wg> wg> <class name="ObjectName" identity="objectNameId" wg> key-generator="SEQUENCE"> wg> <description>"ObjectName"</description> wg> <map-to table="Object_Name"/> wg> <cache-type type="none"/> wg> <field name="objectNameId" type="integer"> wg> <sql name="Object_Name_Id" type="integer"/> wg> </field> wg> <field name="objectCode" type="integer"> wg> <sql name="Object_Code" type="integer"/> wg> </field> wg> <field name="objectNum" type="string"> wg> <sql name="Object_Num" type="varchar"/> wg> </field> wg> <field name="objectDesc" type="string"> wg> <sql name="Object_Desc" type="varchar"/> wg> </field> wg> <field name="objectApp" type="ObjectAppType"> wg> <sql name="Object_App"/> wg> </field> wg> <field name="objectExpiration" type="date"> wg> <sql name="Object_Expiration" type="timestamp"/> wg> </field> wg> <!-- wg> <field name="manyToManyObjectLink" type="ObjectLink" wg> collection="arraylist"> wg> <sql many-key="Object_Name_id"/> wg> </field> wg> --> wg> </class> wg> wg> The final entry, the many-key type, was what failed. The wg> ObjectLink object wg> is just a small object representing the 'link' to a third wg> object which this wg> object has a many-to-many relationship with. The wg> ObjectLink object contains wg> three properties: its own primary key, the key to this wg> object, and the key wg> to the many-to-many linked object. wg> wg> wg> -Ron wg> wg> wg> -----Original Message----- wg> From: Werner Guttmann [mailto:[EMAIL PROTECTED] wg> Sent: Friday, June 03, 2005 7:36 AM wg> To: dev@castor.codehaus.org wg> Subject: RE: [castor-dev] Strange Issue on OQL Query wg> wg> wg> Ronald, wg> wg> first of all, 0.9.6 has been regression tested for about wg> three months before wg> having been released back in February. As far as your wg> problem is concerned, wg> could you create a bug report (as outlined in the bug wg> report guidelines), wg> and we'll take care of your problem (if it turns out to be a genuine wg> problem). wg> wg> As to your problem, can you please show us the mapping file wg> for 'ObjectName' wg> ? wg> wg> Regards wg> Werner wg> wg> wg> -----Original Message----- wg> wg> From: Ronald Rudy [mailto:[EMAIL PROTECTED] wg> wg> Sent: Friday, June 03, 2005 1:30 PM wg> wg> To: dev@castor.codehaus.org wg> wg> Subject: [castor-dev] Strange Issue on OQL Query wg> wg> wg> wg> wg> wg> I'm running Castor 0.9.4.3 . Moving to 0.9.6 caused some wg> wg> minor issues, and wg> wg> I've not the time to drop the latest Castor in and do full wg> wg> regression wg> wg> testing. wg> wg> wg> wg> I have an issue where if I do a select with little or no wg> wg> parameters I get wg> wg> very strange results. wg> wg> wg> wg> First of all, there are only 29 records total for the table wg> wg> I'm pulling wg> wg> from. If I do a straight select (using OQL, e.g. "SELECT o FROM wg> wg> ObjectName") I get not 29, but 30 records. The first wg> wg> record is being placed wg> wg> as the 30th and final record. wg> wg> wg> wg> If I place a WHERE clause on my OQL, which should take away wg> wg> one of the 29 wg> wg> records leaving 28, I still have 30 records being pulled wg> wg> from my OQL Query. wg> wg> wg> wg> Stranger still, if I place an ORDER BY on a string field to wg> wg> alphabetize the wg> wg> resultset, it pulls not 28, 29, or 30, but 34. There wg> wg> doesn't seem to be any wg> wg> sort of pattern to this particular set. For reference, not wg> wg> that it will wg> wg> help, here are the primary keys of the set of 34: wg> wg> wg> wg> 1: 930016 wg> wg> 2: 1961509 wg> wg> 3: 589902 wg> wg> 4: 593437 wg> wg> 5: 586982 wg> wg> 6: 584062 wg> wg> 7: 5002 wg> wg> 8: 85 wg> wg> 9: 84 wg> wg> 10: 99081 wg> wg> 11: 83 wg> wg> 12: 99081 <-- repeat of 10th wg> wg> 13: 83 <-- repeat of 11th wg> wg> 14: 81 wg> wg> 15: 501478 wg> wg> 16: 81 <-- repeat of 14th wg> wg> 17: 87 wg> wg> 18: 325893 wg> wg> 19: 87 <-- repeat of 17th wg> wg> 20: 86 wg> wg> 21: 1064890 wg> wg> 22: 487895 wg> wg> 23: 490621 wg> wg> 24: 487895 <-- repeat of 22nd wg> wg> 25: 863602 wg> wg> 26: 919613 wg> wg> 27: 80 wg> wg> 28: 544421 wg> wg> 29: 781975 wg> wg> 30: 796335 wg> wg> 31: 781975 <-- repeat of 29 wg> wg> 32: 785875 wg> wg> 33: 532108 wg> wg> 34: 535028 wg> wg> wg> wg> wg> wg> After tracking this down, it appears to be caused by a wg> wg> "many-key" type wg> wg> mapping, which in this case is a map to a linking table wg> with another wg> wg> table/object to make a many-to-many type relationship. wg> wg> Removing this fixes wg> wg> the above query, but it then requires that this wg> wg> many-to-many relationship be wg> wg> handled manually. wg> wg> wg> wg> Is there any known resolution for this issue? wg> wg> wg> wg> -Ron wg> wg> wg> wg> wg> wg> ------------------------------------------------- wg> wg> If you wish to unsubscribe from this list, please wg> wg> send an empty message to the following address: wg> wg> wg> wg> [EMAIL PROTECTED] wg> wg> ------------------------------------------------- wg> wg> wg> 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> 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] -------------------------------------------------
