Hi Michael,
I will fix the schema and metadata, assuming that you will add a field
called id to the StateTransitionObj class that will be the primary key.
I will check in the schema and metadata today so you can test with it.
Is this okay with you?
-- Michelle
Craig Russell wrote:
If it is only one field which is persistent, do we have a problem
with application identity? In that case, the field must be the PK.
This is true, and the problem with it is that since it would be the
PK, it cannot generally be written. Additionally there is no
application identity class.
Summarizing, in addition to the fix in the test code we need to
0.0 Fix the test case to catch exceptions and complete.
0.1 Fix the StateTransitionObject to add an int id field with
application-created values, and add an embedded objectid class using
the new field as primary key. (The default constructor should set the
id field and increment the value to make it unique; the objectid class
should be embedded and have the same int id field)
1) fix the SQL schema
2) add the missing .orm files
3) fix the .jdo files
...
I'm not sure which fields of class
"org.apache.jdo.tck.pc.lifecycle.StateTransitionObj" are persistent.
Can you also help on the application/datastore issue? Is it
reasonable to define a second persistent field?
Yes, see above.
So, Michael,
If you have the JPOX environment set up, you should be able to fix the
StateTransitionObj.java and
the PMsCanSharePCClassesButNotPCInstances.java, the .jdo and .orm files.
Just coordinate with Michelle so you don't conflict on the schema1.sql
and schema2.sql files. Since it's just adding a table, there should be
minimal conflicts.
Thanks,
Craig
