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:
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.
