'ADPT_PK_IDX' is not a column in table or VTI 'APPLICATIONIDENTITY0.COLLECTION_OF_OBJECT1'

• Key: JDO-121
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Erik Bengtson
• Reporter: Michelle Caisse
• Component/s: tck2
• Fix Version/s: JDO 2 beta

Description

JPOX changes name of ID column in join tables for collection of objects field. Looking for a pk?

test(org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections)javax.jdo.JDODataStoreException: Add request failed : INSERT INTO applicationidentity0.COLLECTION_OF_OBJECT1 (IDENTIFIER,ADPT_PK_IDX,INTVAL,STRINGVAL) VALUES (?,?,?,?)
at org.jpox.store.rdbms.scostore.NormalSetStore.add(NormalSetStore.java:578)
at org.jpox.sco.SCOUtils.updateStoreWithCollection(SCOUtils.java:461)
at org.jpox.store.mapping.container.CollectionMapping.postUpdate(CollectionMapping.java:279)
at org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266)
at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1834)
at org.jpox.store.StoreManager.update(StoreManager.java:768)
at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4042)
at org.jpox.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:2932)
at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:432)
at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:97)
at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:197)
at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128)
at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106)
NestedThrowablesStackTrace:
ERROR 42X14: 'ADPT_PK_IDX' is not a column in table or VTI 'APPLICATIONIDENTITY0.COLLECTION_OF_OBJECT1'.
at org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
at org.apache.derby.impl.sql.compile.ResultColumn.bindResultColumnByName(ResultColumn.java)
at org.apache.derby.impl.sql.compile.ResultColumnList.bindResultColumnsByName(ResultColumnList.java)
at org.apache.derby.impl.sql.compile.InsertNode.bind(InsertNode.java)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java)
at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(EmbedPreparedStatement.java)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(EmbedPreparedStatement20.java)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(EmbedPreparedStatement30.java)
at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Driver30.java)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java)
at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190)
at org.jpox.store.rdbms.scostore.NormalSetStore.add(NormalSetStore.java:538)
at org.jpox.sco.SCOUtils.updateStoreWithCollection(SCOUtils.java:461)
at org.jpox.store.mapping.container.CollectionMapping.postUpdate(CollectionMapping.java:279)
at org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:266)
at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:1834)
at org.jpox.store.StoreManager.update(StoreManager.java:768)
at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4042)
at org.jpox.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:2932)
at org.jpox.NonmanagedTransaction.commit(NonmanagedTransaction.java:432)
at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.runTest(TestCollectionCollections.java:97)
at org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections.test(TestCollectionCollections.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:197)
at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128)
at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106)

Comments

[Michelle Caisse]

Comments from Andy:

CollectionCollections has a field Object1 that is a
Collection<SimpleClass> embedded in the join table. The TCK is expecting a
schema with join table having columns for the FK back to the owner object,
and the fields for the element. JPOX looks at this from a different angle and
requires a PK on this join table and so, since we don't have an id for the
embedded SimpleClass, we add an "adapter index" column to form the PK. As has
been discussed in the past, the user has no obvious way of saying that they
don't want a PK applying to the join table. They have the <primary-key>
element but that is only currently for specifying the pk name.

In addition, since the test is using java.util.Collection, which can allow
duplicates, the JDO impl can utilise an "adapter index" in the same way to
allow duplicates in the join table.

[Craig Russell]

The mapping for embedded Collection elements needs to contain a column to allow duplicates, similar to the column for ordering collections that are Lists or Arrays. We can use the existing element <order> for this purpose.

The jdo metadata for the embedded Collection is now:

<field name="CollectionOfObject1" >
<collection element-type="org.apache.jdo.tck.pc.fieldtypes.SimpleClass" embedded-element="true">
</collection>
</field>

The orm metadata is:

            <field name="CollectionOfObject1"
                   table="COLLECTION_OF_OBJECT1">
                <join column="IDENTIFIER"/>
                <element>
                  <embedded>
                    <field name="id" column="ID"/>
                    <field name="intField" column="INTVAL"/>
                    <field name="stringField" column="STRINGVAL"/>
                  </embedded>
                </element>
                <order column="ALLOW_DUPLICATES"/>
            </field>

The schema is:

CREATE TABLE COLLECTION_OF_OBJECT1
(
    IDENTIFIER INTEGER REFERENCES COLLECTION_COLLECTIONS NOT NULL,
    ALLOW_DUPLICATES BIGINT NOT NULL,
    ID BIGINT NOT NULL,
    INTVAL INTEGER NOT NULL,
    STRINGVAL VARCHAR(128) NOT NULL
);

This configuration produces a different error from the original bug report, because JPOX does not embed the primary key field. This appears to be an issue only with application identity. Since the primary key field is an application field and the instance will not work without it, this seems to be an error in the JPOX implementation.

[Andy Jefferson]

While it is a nice idea to overload <order> for Collections/Sets, it is not part of the spec I have in front of me.
<spec>
18.14.8 ELEMENT order
This element specifies the mapping for the ordering component of arrays and lists.
</spec>
If at some point we have an element in the spec for allowing dups, then allowing support will be trivial.

[Craig Russell]

I've proposed to allow the <order> element to be used for allowing duplicates.

begin forwarded mail:

Currently the spec does not appear to support an element that allows mapping a collection (duplicates allowed) to a table with a column specifically to allow duplicates. We have an <order> element but it seems to be just for ordering.

I'd like to propose using the order element to be used for duplicates. As a side effect, the collection might be ordered but that's not a requirement. Or should it be?

<spec>
ELEMENT order
This element specifies the mapping for the ordering component of arrays and lists.
</spec>

<proposed>
ELEMENT order
This element specifies the mapping for the ordering component of arrays and lists, and for the mapping that allows duplicates in a collection.
</proposed>

[Michelle Caisse]

Expert group has approved using the <order> element to allow duplicates.

[Andy Jefferson]

and JPOX has been supporting it for a week or more. Is this in the TCK yet?

[Michelle Caisse]

<order> to allow duplicates works. Test errs/fails for other reasons now.

[Michael Bouschen]

Reopened to set the Fix Version/s field to JDO 2 beta.