|
Home > Archive > Apache JDO Project > August 2005 > Minutes: JDO TCK Conference Call Friday, Aug 19, 9 am PST
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Minutes: JDO TCK Conference Call Friday, Aug 19, 9 am PST
|
|
| Craig Russell 2005-08-19, 5:45 pm |
| | |
| Andy Jefferson 2005-08-20, 2:45 am |
| > FieldsOfObject still doesn't work. JDO-120. AI: Need feedback from
> Erik or Andy.
Feedback : TestFieldsOfObject.java is not correct. It's still trying to use
Object values that are String, and Integer even though the metadata is now
specifying that the "implementation" of the Object field is SimpleClass. The
"firstValue", "secondValue" values need changing to be SimpleClass objects.
JPOX is throwing a ClassCastException as is required by the spec 6.4.3
<spec>
If an implementation restricts instances to be assigned to the field, a
ClassCastException must be thrown at the time of any incorrect assignment.
</spec>
though the message currently given in the exception could be made more
explicit.
--
Andy
Java Persistent Objects - JPOX
| |
| Andy Jefferson 2005-08-20, 7:45 am |
| > CollectionOfObject doesn't work JDO-121. AI: Need feedback from Erik
> or Andy.
Feedback : 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.
--
Andy
Java Persistent Objects - JPOX
| |
| Michelle Caisse 2005-08-20, 5:45 pm |
| You're right, Andy. I will make this change.
-- Michelle
Andy Jefferson wrote:
>
>Feedback : TestFieldsOfObject.java is not correct. It's still trying to use
>Object values that are String, and Integer even though the metadata is now
>specifying that the "implementation" of the Object field is SimpleClass. The
>"firstValue", "secondValue" values need changing to be SimpleClass objects.
>
>JPOX is throwing a ClassCastException as is required by the spec 6.4.3
><spec>
>If an implementation restricts instances to be assigned to the field, a
>ClassCastException must be thrown at the time of any incorrect assignment.
></spec>
>though the message currently given in the exception could be made more
>explicit.
>
>
>
>
| |
| Craig Russell 2005-08-26, 7:45 am |
| | |
| Andy Jefferson 2005-08-26, 7:45 am |
| Hi Craig,
>
> There is a natural PK for the join table. It's a combination of the
> FK plus the column mapped to the id field. If this were defined to be
> the PK for the join table in the schema, would that work?
If the implementation can be handed a definition of the columns to use in the
PK for the join table, then the implementation can use that, and saves it
having to resort to adding its own magic - which would be a good thing from a
TCK perspective.
In this particular case as you say, the SimpleClass has a field "id" that is
persistent, and so will be present in the join table whilst embedded and, as
long as its value is consistent with use as part of the PK, could be used as
such.
Looking at the PFD 18.7, I see you've added that the user can specify
<join table="...">
<primary-key name="...">
<column name="..."/>
<column name="..."/>
</primary-key>
</join>
You'll just have to give me time to implement this ;-). JPOX supports the
<primary-key name="..."/> syntax but not the subelement columns yet.
Section 18.7 doesn't mention what happens if the user doesn't specify this PK
definition, consequently JPOX will just define the PK how it does at the
moment if nothing is provided.
--
Andy
Java Persistent Objects - JPOX
|
|
|
|
|