db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <Michelle.Cai...@Sun.COM>
Subject Re: tck test status
Date Thu, 26 May 2005 16:15:59 GMT

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 

-- 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
>>    [java] NestedThrowables:
>>    [java] SQL Exception: 'ADPT_PK_IDX' is not a column in table or VTI
>>'TCKUSER.EMPLOYEE_PHONENO_TYPE'.>javax.jdo.JDODataStoreException: Put
>>    [java]      at
>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
>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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message