I didn't intend to mean regression testing for Castor, I meant for my
application. There wasn't an error in Castor 0.9.6, it was an issue of
compatibility somewhere within my application that I didn't have time to
address - sorry for the confusion. :)
Here's a mapping snippet:
<class name="ObjectName" identity="objectNameId"
key-generator="SEQUENCE">
<description>"ObjectName"</description>
<map-to table="Object_Name"/>
<cache-type type="none"/>
<field name="objectNameId" type="integer">
<sql name="Object_Name_Id" type="integer"/>
</field>
<field name="objectCode" type="integer">
<sql name="Object_Code" type="integer"/>
</field>
<field name="objectNum" type="string">
<sql name="Object_Num" type="varchar"/>
</field>
<field name="objectDesc" type="string">
<sql name="Object_Desc" type="varchar"/>
</field>
<field name="objectApp" type="ObjectAppType">
<sql name="Object_App"/>
</field>
<field name="objectExpiration" type="date">
<sql name="Object_Expiration" type="timestamp"/>
</field>
<!--
<field name="manyToManyObjectLink" type="ObjectLink"
collection="arraylist">
<sql many-key="Object_Name_id"/>
</field>
-->
</class>
The final entry, the many-key type, was what failed. The ObjectLink object
is just a small object representing the 'link' to a third object which this
object has a many-to-many relationship with. The ObjectLink object contains
three properties: its own primary key, the key to this object, and the key
to the many-to-many linked object.
-Ron
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: Friday, June 03, 2005 7:36 AM
To: dev@castor.codehaus.org
Subject: RE: [castor-dev] Strange Issue on OQL Query
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]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
