Looks like the list doesn't allow attachments, if anyone wants to see the diagram, it is here: http://leadgroupinc.com/gallery/DrunkOMatic/diagram.jpg
-----Original Message----- From: Lemke, Wesley [mailto:[EMAIL PROTECTED] Sent: Monday, February 14, 2005 4:12 PM To: [email protected] Subject: Persisting Inheritance.. I have already posted this to the user list, but was unable to resolve this issue. I then started looking into the OJB code, and have narrowed the problem down, but still need some help. Here is the situation: I have 3 classes defined as follows: public class Shape { Long id; String shapeInfo = "shape"; List sides = new ArrayList(); ... } public class Square extends Shape { Long id; String squareInfo = "square"; ... } public class Side { Long id; Shape shape; ... } A simple class diagram is attached. Here is the repository.xml file: <jdbc-connection-descriptor jcd-alias="default" default-connection="true" platform="Db2" jdbc-level="1.0" jndi-datasource-name="jdbc/AffinityDS" batch-mode="false" > <sequence-manager className="org.apache.ojb.broker.util.sequence.SequenceManagerNativeImpl "> <attribute attribute-name="autoNaming" attribute-value="true"/> </sequence-manager> </jdbc-connection-descriptor> <class-descriptor class="model.Shape" table="shape" > <field-descriptor name="id" column="shape_id" jdbc-type="BIGINT" primarykey="true" autoincrement="true" /> <field-descriptor name="shapeInfo" column="shape_info" jdbc-type="VARCHAR" /> <collection-descriptor name="sides" element-class-ref="model.Side" auto-delete="true" auto-update="true" > <inverse-foreignkey field-ref="side" /> </collection-descriptor> </class-descriptor> <class-descriptor class="model.Square" table="square" > <field-descriptor name="id" column="square_id" jdbc-type="BIGINT" primarykey="true" autoincrement="true" /> <field-descriptor name="squareInfo" column="square_info" jdbc-type="VARCHAR" /> <reference-descriptor name="super" class-ref="model.Shape" auto-retrieve="true" auto-update="true" auto-delete="true" > <foreignkey field-ref="id"/> </reference-descriptor> </class-descriptor> <class-descriptor class="model.Side" table="side" > <field-descriptor name="id" column="side_id" jdbc-type="BIGINT" primarykey="true" autoincrement="true" /> <field-descriptor name="shape" column="shape_id" jdbc-type="BIGINT" access="anonymous" /> <reference-descriptor name="shape" class-ref="model.Shape"> <foreignkey field-ref="shape"/> </reference-descriptor> </class-descriptor> Here is the code I am using: broker.beginTransaction(); Square square = new Square(); for (int i = 0; i < 4; i++) { Side side = new Side(); square.addSide(side); side.setShape(square); } broker.store(square); broker.commitTransaction(); Here is what the database looks like after I run this code: Shape: shape_id shape_info -3 shape Square: square_id square_info -3 square Side: side_id shape_id -4 -2 -5 -2 -6 -2 -7 -2 -8 -2 As you can see the foreign key in the Side table is incorrect (or the foreign keys in the shape/square tables are incorrect). When you try to retrieve the Square object, the join will fail. I have tracked this down to this area of the code (OJB 1.0.1, org.apache.ojb.broker.core.PersistenceBrokerImpl.java, line 1033 or so): for (int i = 0; i < objFkFields.length; i++) { fld = objFkFields[i]; /* arminw: we set the FK value when the extracted PK fields from the referenced object are not null at all or if null, the FK field was not a PK field of target object too. Should be ok, because the values of the extracted PK field values should never be null and never change, so it doesn't matter if the target field is a PK too. */ if(refPkValues != null || !fld.isPrimaryKey()) { //Comment by me: This is where the key gets changed. It also looks like the keys //to the Side objects get changed, but they don't get persisted to the database correctly.... fld.getPersistentField().set(targetObject, refPkValues != null ? refPkValues[i].getValue(): null); } } See my comment above in the code (I believe they are correct). Can anyone offer any assistance or guidance on what the problem could be? I've been working on this issue (in different ways) for a few weeks now. If any more information is needed, let me know. Thanks in advance, Wes --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
