11-09-05 10:45 PM
Hi Christian,
In JDO 1, we allowed the implementation to decide how to store fields
of type Object and interfaces. Most compliant implementations simply
serialized the instances. Job done. But in JDO 2, there is more
explicit control over the mapping, and not all mappings can be used
portably with Object and interfaces.
The issue is that, in general, mapping an instance of type Object to
a fixed-schema datastore (e.g. RDBMS) is not a solved problem. We
have introduced a few explicit mapping types in JDO 2 that allow more
control by the deployer over how persistent instances are represented
in the datastore, and not all of these explicit mapping types can be
reasonably implemented for the target datastores.
We have added metadata to say that instances should be mapped:
serialized-element: the instance is stored serialized in a column of
the join table
embedded-element: the instance is stored field-by-field in the join
table
"neither of the above": the instance is stored in its own table and a
reference is stored in the join table
It's straightforward to map serialized-element for Object and
SimpleInterface. Just serialize the instance and store the stream in
the blob column.
For embedded-element, the structure of what you're storing needs to
be known. For Object, there is no structure unless you scan the
entire known universe of persistence-capable classes and use a column
for each persistent field. But this has no practical value.
For neither serialized nor embedded, the referenced type needs to be
known in order to have a column that refers to the target table.
Without knowing the target type, you would have to declare a column
referring to each primary key column of any persistence-capable
class, and store the corresponding key value in the appropriate
column. Again, I don't know of any practical use-case.
We have a similar issue with fields of type Object and interface. I'm
proposing a new metadata attribute (Issue 139) for field in order to
allow the deployer to specify a more specific field type, so that
deployment to RDBMS specifying non-serialized storage is possible.
Regards,
Craig
On Nov 9, 2005, at 3:39 AM, Christian Ernst wrote:
> Hy !
> I have a question related to the Metadata changes done in 330689
> for the PC Classes used for Collection Field tests.
> Why have the variants for Collection fields with element-
> type=java.lang.Object or element-type=SimpleInterface
> been changed to element-type=SimpleClass ( concrete PC class ) in
> the Metadata ?
>
> mfg
> Christian
>
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
[ Post a follow-up to this message ]
| 
