Apache JDO Project - tck test status

Author

tck test status

Michelle Caisse

2005-06-06, 7:49 am

Hi,

Below is a summary four test errors that are responsible for 90 out of a
total of 115 errors when running the tck on jpox/derby. The fourth one
listed is a test cleanup problem logged as JIRA JDO-48. Could the JPOX
team please take a look at the others?

14 tests fail with "javax.jdo.JDOUserException: No implementation
classes found for interface..."
org.apache.jdo.tck.models.fieldtypes.TestArrayListCollections
org.apache.jdo.tck.models.fieldtypes.TestCollectionCollections
org.apache.jdo.tck.models.fieldtypes.TestFieldsOfSimpleInterface
org.apache.jdo.tck.models.fieldtypes.TestHashMapStringKeyCollections
org.apache.jdo.tck.models.fieldtypes.TestHashMapStringValueCollections
org.apache.jdo.tck.models.fieldtypes.TestHashSetCollections
org.apache.jdo.tck.models.fieldtypes.TestHashtableStringKeyCollections
org.apache.jdo.tck.models.fieldtypes. TestHashtableStringValueCollections)java
x.j
org.apache.jdo.tck.models.fieldtypes.TestLinkedListCollections
org.apache.jdo.tck.models.fieldtypes.TestListCollections
org.apache.jdo.tck.models.fieldtypes.TestMapStringKeyCollections
org.apache.jdo.tck.models.fieldtypes.TestMapStringValueCollections
org.apache.jdo.tck.models.fieldtypes.TestSetCollections
org.apache.jdo.tck.models.fieldtypes.TestVectorCollections

18 tests fail:
[java] 38)
test(org.apache.jdo.tck.query.Cast)javax.jdo.JDOUserException: Field
"org.apache.jdo.tck.pc.company.Employee.reviewedProjects" has been
defined as "mapped-by" the field
"org.apache.jdo.tck.pc.company.Project.reviewers" yet this is of an
incorrect type (java.util.Set). The field that is set as the "mapped-by"
must be of type "org.apache.jdo.tck.pc.company.Employee"
[java] at
org.jpox.store.rdbms.scostore.InverseSetStore.<init>(InverseSetStore.java:141)
[java] at
org.jpox.store.rdbms.RDBMSManager.newStore(RDBMSManager.java:599)
[java] at
org.jpox.store.mapping.CollectionMapping.getSetStore(CollectionMapping.java:79)
[java] at
org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:155)
[java] at
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:305)
[java] at
org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1673)
[java] at org.jpox.store.StoreManager.insert(StoreManager.java:634)
[java] at
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:2940)
[java] at
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:2913)
[java] at
org.jpox.AbstractPersistenceManager. internalMakePersistent(AbstractPersisten
ceManager.java:959)
[java] at
org.jpox.AbstractPersistenceManager. makePersistent(AbstractPersistenceManage
r.java:1007)
[java] at
org.jpox.store.rdbms.scostore.InverseSetStore.add(InverseSetStore.java:387)
[java] at
org.jpox.store.rdbms.scostore.InverseSetStore.addAll(InverseSetStore.java:428)
[java] at
org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:155)
[java] at
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:305)
[java] at
org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1673)
[java] at org.jpox.store.StoreManager.insert(StoreManager.java:634)
[java] at
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:2940)
[java] at
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:2913)
[java] at
org.jpox.AbstractPersistenceManager. internalMakePersistent(AbstractPersisten
ceManager.java:959)
[java] at
org.jpox.AbstractPersistenceManager. makePersistent(AbstractPersistenceManage
r.java:995)
[java] at
org.apache.jdo.tck.query.QueryTest.loadCompanyModel(QueryTest.java:122)
[java] at org.apache.jdo.tck.query.Cast.test(Cast.java:64)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:149)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:112)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:90)

24 tests fail with "A truncation error was encountered trying to shrink
CHAR '79' to length 1" (or ... CHAR '65535' to length 1)
[java] 52)
test(org.apache.jdo.tck.query.IgnoreCacheFalse)javax.jdo.JDODataStoreException:
Insert request failed: INSERT INTO PRIMITIVETYPES
(INTNULL,BIGINTEGER,LONGNULL,SHORTNULL,P
RIMITIVETYPES,BIGDECIMAL,BOOLEANNULL,DOU
BLENOTNULL,BYTENULL,CHARNOTNULL,BOOLEANN
OTNULL,FLOATNOTNULL,INTNOTNULL,FLOATNULL
,SHORTNOTNULL,LONGNOTNULL,BYTENOTNULL,ST
RINGNULL,DOUBLENULL,CHARNULL,DATENULL)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
[java] at
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:294)
[java] at
org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1673)
[java] at org.jpox.store.StoreManager.insert(StoreManager.java:634)
[java] at
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:2940)
[java] at
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:2913)
[java] at
org.jpox.AbstractPersistenceManager. internalMakePersistent(AbstractPersisten
ceManager.java:959)
[java] at
org.jpox.AbstractPersistenceManager. makePersistent(AbstractPersistenceManage
r.java:995)
[java] at
org.apache.jdo.tck.query.QueryTest.insertPrimitiveTypes(QueryTest.java:212)
[java] at
org.apache.jdo.tck.query.QueryTest.loadPrimitiveTypes(QueryTest.java:179)
[java] at
org.apache.jdo.tck.query.IgnoreCacheFalse.test(IgnoreCacheFalse.java:68)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:149)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:112)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:90)
[java] NestedThrowablesStackTrace:
[java] ERROR 22001: A truncation error was encountered trying to
shrink CHAR '79' to length 1.
[java] at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
[java] at
org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(SQLChar.java)
[java] at
org.apache.derby.iapi.types.SQLChar.normalize(SQLChar.java)
[java] at
org.apache.derby.iapi.types.SQLChar.normalize(SQLChar.java)
[java] at
org.apache.derby.iapi.types.DataTypeDescriptor.normalize(DataTypeDescriptor.java)
[java] at
org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeRow(NormalizeResultSet.java)
[java] at
org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java)
[java] at
org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java)
[java] at
org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java)
[java] at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java)
[java] at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java)
[java] at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java)
[java] at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java)
[java] at
org.jpox.store.rdbms.request.Request.executeUpdate(Request.java:69)
[java] at
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:253)
[java] at
org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1673)
[java] at org.jpox.store.StoreManager.insert(StoreManager.java:634)
[java] at
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:2940)
[java] at
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:2913)
[java] at
org.jpox.AbstractPersistenceManager. internalMakePersistent(AbstractPersisten
ceManager.java:959)
[java] at
org.jpox.AbstractPersistenceManager. makePersistent(AbstractPersistenceManage
r.java:995)
[java] at
org.apache.jdo.tck.query.QueryTest.insertPrimitiveTypes(QueryTest.java:212)
[java] at
org.apache.jdo.tck.query.QueryTest.loadPrimitiveTypes(QueryTest.java:179)
[java] at
org.apache.jdo.tck.query.IgnoreCacheFalse.test(IgnoreCacheFalse.java:68)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:149)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:112)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:90)

34 tests fail with violation of foreign key constraint (JDO-48)
test(org.apache.jdo.tck.query. AssignmentPrePostIncrementDecrementNotSu
pported)javax.jdo.JDODataStoreException:
Delete request failed: DELETE FROM PCPOINT WHERE ID = ?
.... [java] ERROR 23503: DELETE on table 'PCPOINT' caused a violation
of foreign key constraint 'SQL050519025602280' for key (1167). The
statement has been rolled back.

-- Michelle

Andy Jefferson

2005-06-06, 7:49 am

> Below is a summary four test errors that are responsible for 90 out of a
> total of 115 errors when running the tck on jpox/derby. The fourth one
> listed is a test cleanup problem logged as JIRA JDO-48. Could the JPOX
> team please take a look at the others?

> test(org.apache.jdo.tck.query.Cast)javax.jdo.JDOUserException: Field
> "org.apache.jdo.tck.pc.company.Employee.reviewedProjects" has been
> defined as "mapped-by" the field
> "org.apache.jdo.tck.pc.company.Project.reviewers" yet this is of an
> incorrect type (java.util.Set). The field that is set as the "mapped-by"
> must be of type "org.apache.jdo.tck.pc.company.Employee"

Well you have a MetaData specification that has a "mapped-by" that points to a
Set object in the other class. Is this to represent a M-N or 1-N
relationship ? I see nothing in the JDO 2 spec that defines the metadata for
M-N relationships. Would be nice if the spec included a definition of what
implementations are supposed to accept because without it, it is left open to
interpretation, which is a bad thing.

JPOX requires that any mapped-by field is of the type of the class that it is
defined in.

With 1-N :-
class A
{
Set b;
}
class B
{
A a;
}
You define the metadata for A field b to have a mapped-by as "a".

With a M-N :-
class A
{
Set b;
}
class B
{
Set b;
}
With JPOX currently you don't use mapped-by, and you use <join/> because for a
M-N you need a join. I see no <join> in the SVN metadata.

HTH
--
Andy
JPOX - Java Persistent Objects

Craig Russell

2005-06-06, 7:49 am

Michelle Caisse

2005-06-06, 7:49 am

Hi, Andy,

The orm metadata in svn for the Project class uses a join:

<class name="Project" table="projects">
<field name="projid" column="PROJID" primary-key="true"/>
<field name="name" column="NAME"/>
<field name="budget" column="BUDGET"/>
<field name="reviewers" table="project_reviewer">
<join column="PROJID"/>
<element column="REVIEWER"/>
</field>
<field name="members" table="project_member">
<join column="PROJID"/>
<element column="MEMBER"/>
</field>
</class>

How would you map the reviewedProjects field in Employees? This is
where we use mapped-by:

<class name="Employee">
...
<field name="reviewedProjects" mapped-by="reviewers"/>
<field name="projects" mapped-by="members"/>
...
</class>

-- Michelle

Andy Jefferson wrote:

>
>
>
>
>Well you have a MetaData specification that has a "mapped-by" that points to a
>Set object in the other class. Is this to represent a M-N or 1-N
>relationship ? I see nothing in the JDO 2 spec that defines the metadata for
>M-N relationships. Would be nice if the spec included a definition of what
>implementations are supposed to accept because without it, it is left open to
>interpretation, which is a bad thing.
>
>JPOX requires that any mapped-by field is of the type of the class that it is
>defined in.
>
>With 1-N :-
>class A
>{
> Set b;
>}
>class B
>{
> A a;
>}
>You define the metadata for A field b to have a mapped-by as "a".
>
>
>With a M-N :-
>class A
>{
> Set b;
>}
>class B
>{
> Set b;
>}
>With JPOX currently you don't use mapped-by, and you use <join/> because for a
>M-N you need a join. I see no <join> in the SVN metadata.
>
>HTH
>--
>Andy
>JPOX - Java Persistent Objects
>
>

Andy Jefferson

2005-06-06, 7:49 am

Craig/Michelle,

Craig wrote:
> In the company-derby.orm, the Project is mapped thus:
>
> <class name=3D"Project" table=3D"projects">
> <field name=3D"projid" column=3D"PROJID" primary-key=3D"true=
"/>
> <field name=3D"reviewers" table=3D"project_reviewer">
> <join column=3D"PROJID"/>
> <element column=3D"REVIEWER"/>
> </field>

Yes. I must have been looking at the wrong file. It's all clear now :-)
=20
[I always put the orm and jdo files together with the classes so that I don=
't=20
have to go navigating all over the place to find what relates to a particul=
ar=20
relationship/class ... just my preference though]

Craig wrote:
> I don't know what more information is needed in order to map this.
> Could you explain your algorithm and tell us where you arrive which
> needs more information?

OK. You'll just have to put it down to "not currently supported by JPOX" wi=
th=20
that MetaData definition. We support M-N just in a different way.

Michelle wrote:
> How would you map the reviewedProjects field in Employees? =A0This is=20
> where we use mapped-by:

Well we don't currently. JPOX supports M-N as 2 1-N relationships that use =
a=20
(possibly common) join table (hence they dont require the mapped-by how we=
=20
currently do it).

Craig wrote:
> I do have an action item for Chapter 15 that should explain this better.

That would be great :-)

=2D-
Andy
JPOX - Java Persistent Objects

Michelle Caisse

2005-06-06, 7:49 am

Andy,

Andy Jefferson wrote:

>[I always put the orm and jdo files together with the classes so that I don't
>have to go navigating all over the place to find what relates to a particular
>relationship/class ... just my preference though]
>
>
>
Just FYI, our system of scattering the metadata in their own trees is to
facilitate having multiple metadata files per class for testing. It's
probably not a good idea for a real application.

>
>OK. You'll just have to put it down to "not currently supported by JPOX" with
>that MetaData definition. We support M-N just in a different way.
>
>
>
Do you have an idea of when you might support this? The new metadata
tests I'm working on use the company model and this mapping, so I'm
wondering if I should bother to temporarily remap them for debugging.

-- Michelle

Andy Jefferson

2005-06-06, 7:49 am

> >OK. You'll just have to put it down to "not currently supported by JPOX"
>
> Do you have an idea of when you might support this? The new metadata
> tests I'm working on use the company model and this mapping, so I'm
> wondering if I should bother to temporarily remap them for debugging.

Hi Michelle,

sometime in the next month hopefully. Maybe sooner ...

--
Andy
JPOX - Java Persistent Objects

Andy Jefferson

2005-06-06, 7:49 am

> > Do you have an idea of when you might support this? The new metadata
[vbcol=seagreen]
> sometime in the next month hopefully. Maybe sooner ...

You can just use the workaround of specifying <join/> at BOTH ends of the
relationship for now. The real problem is that currently JPOX isn't
supporting the specification of <join> on just one end of a M-N - it needs it
on both

--
Andy
JPOX - Java Persistent Objects

Michelle Caisse

2005-06-06, 7:49 am

Hi, Andy,

Andy Jefferson wrote:

>
>
>
Cool.
[vbcol=seagreen]
>
>You can just use the workaround of specifying <join/> at BOTH ends of the
>relationship for now. The real problem is that currently JPOX isn't
>supporting the specification of <join> on just one end of a M-N - it needs it
>on both
>
>
I've done that, but then JPOX seems to want a primary key in the join
table and supplies it, though there is none in the schema or metadata.

[java] [FATAL] tck - Exception during setUp or runtest:
<javax.jdo.JDODataStoreException: Put request failed : INSERT INTO
EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?)
[java] NestedThrowables:
[java] SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI
'TCKUSER.EMPLOYEE_PHONENO_TYPE'.>javax.jdo.JDODataStoreException: Put
request failed : INSERT INTO EMPLOYEE_PHONENO_TYPE
(PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?)
[java] at
org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:462)

-- Michelle

Michelle Caisse

2005-06-06, 7:49 am

Andy,

I see that you and Craig had a discussion about the join table pk issue
on the jpox forum http://www.jpox.org/servlet/forum/v...ead?thread=1975

-- Michelle

Michelle Caisse wrote:

> Hi, Andy,
>
> Andy Jefferson wrote:
>
> Cool.
>
> I've done that, but then JPOX seems to want a primary key in the join
> table and supplies it, though there is none in the schema or metadata.
>
> [java] [FATAL] tck - Exception during setUp or runtest:
> <javax.jdo.JDODataStoreException: Put request failed : INSERT INTO
> EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?)
> [java] NestedThrowables:
> [java] SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI
> 'TCKUSER.EMPLOYEE_PHONENO_TYPE'.>javax.jdo.JDODataStoreException: Put
> request failed : INSERT INTO EMPLOYEE_PHONENO_TYPE
> (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?)
> [java] at
> org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:462)
>
> -- Michelle
>
>
>

Andy Jefferson

2005-06-06, 7:49 am

> I've done that, but then JPOX seems to want a primary key in the join
> table and supplies it, though there is none in the schema or metadata.
>
> [java] [FATAL] tck - Exception during setUp or runtest:
> <javax.jdo.JDODataStoreException: Put request failed : INSERT INTO
> EMPLOYEE_PHONENO_TYPE (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?)
> [java] NestedThrowables:
> [java] SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI
> 'TCKUSER.EMPLOYEE_PHONENO_TYPE'.>javax.jdo.JDODataStoreException: Put
> request failed : INSERT INTO EMPLOYEE_PHONENO_TYPE
> (PHONENO,EMPID,ADPT_PK_IDX,"TYPE") VALUES (?,?,?,?)
> [java] at
> org.jpox.store.rdbms.scostore.NormalMapStore.put(NormalMapStore.java:462)

Michelle,

This is a different issue to the one before. You previously had a M-N between
Employee and Project - and so adding the <join> to the other end should have
fixed that, presumably it did.

What is this relationship causing the issue ? I'm guessing a Map in Person of
<String, String>. It is a perfectly valid thing for an impl to want to put a
PK on any table. It is also a valid thing for an impl to add additional
columns where required to allow duplicates etc. Depends on the exact nature
of this relation in question. This page
http://www.jpox.org/docs/1_1/relationships_1_N_map.html
shows what JPOX currently does for Maps. If you can identify which one you
have, then maybe Erik or I can remember why there is an ADPT_PK_IDX column
being added in this particular situation.

PS. Next nightly build (20050527) will *not* need the use of <join> on both
ends of a M-N, so you can have a "mapped-by" on one end and <join> on the
other end of the M-N as you had before.

--
Andy
JPOX - Java Persistent Objects

Michelle Caisse

2005-06-06, 7:49 am

Andy,

Yes, this is a different issue. Using the <join> fixed the previous
problem I was running into.

In the TCK, we are starting with pre-defined schemas and mappings from
the classes to the schemas. There are other valid schema/mapping sets,
but we can't just let the vendors autogenerate schema to pass because

(1) We can't test all the mapping metadata if we do that.
(2) Not all implementations will have automatic schema generation.

Apparently there is a gap in the spec around specifying the PK for a
join table, so this is a tricky case. We have to find some solution to
that.

-- Michelle

Andy Jefferson wrote:

>
>Michelle,
>
>This is a different issue to the one before. You previously had a M-N between
>Employee and Project - and so adding the <join> to the other end should have
>fixed that, presumably it did.
>
>What is this relationship causing the issue ? I'm guessing a Map in Person of
><String, String>. It is a perfectly valid thing for an impl to want to put a
>PK on any table. It is also a valid thing for an impl to add additional
>columns where required to allow duplicates etc. Depends on the exact nature
>of this relation in question. This page
>http://www.jpox.org/docs/1_1/relationships_1_N_map.html
>shows what JPOX currently does for Maps. If you can identify which one you
>have, then maybe Erik or I can remember why there is an ADPT_PK_IDX column
>being added in this particular situation.
>
>
>PS. Next nightly build (20050527) will *not* need the use of <join> on both
>ends of a M-N, so you can have a "mapped-by" on one end and <join> on the
>other end of the M-N as you had before.
>
>
>

Craig Russell

2005-06-06, 7:49 am

Andy Jefferson

2005-06-06, 7:49 am

> Apparently there is a gap in the spec around specifying the PK for a
> join table, so this is a tricky case. We have to find some solution to
> that.

Hi Michelle,

JPOX next nightly build (20050528) will only add/require this ADPT_PK_IDX
column if the Map/Set uses a non-PC key and where the column type of the key
is something that cannot be part of the primary key (with the RDBMS being
used). For example, if using keys that are stored as BLOBs then many RDBMS
will not allow this column to be part of the PK.

In your example where you have an object of type A with a Map<String,String>
then (as long as your RDBMS allows VARCHAR/CHAR columns to be part of the PK)
then it will now require a join table with form
A_ID_OID (+)
STRING_KEY (+)
STRING_VAL
and the PK for this table will be (A_ID_OID,STRING_KEY).

This hopefully will alleviate some of the problems you've been seeing. More
may be required.

--
Andy
JPOX - Java Persistent Objects

Michelle Caisse

2005-06-06, 7:49 am

This sounds great, Andy! I'll try it out ASAP.

Thanks very much,
Michelle

Andy Jefferson wrote:
>
>
> Hi Michelle,
>
> JPOX next nightly build (20050528) will only add/require this ADPT_PK_IDX
> column if the Map/Set uses a non-PC key and where the column type of the key
> is something that cannot be part of the primary key (with the RDBMS being
> used). For example, if using keys that are stored as BLOBs then many RDBMS
> will not allow this column to be part of the PK.
>
> In your example where you have an object of type A with a Map<String,String>
> then (as long as your RDBMS allows VARCHAR/CHAR columns to be part of the PK)
> then it will now require a join table with form
> A_ID_OID (+)
> STRING_KEY (+)
> STRING_VAL
> and the PK for this table will be (A_ID_OID,STRING_KEY).
>
> This hopefully will alleviate some of the problems you've been seeing. More
> may be required.
>
>