db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: JDO TCK 20 Metadata Changes in 330689
Date Wed, 09 Nov 2005 20:00:11 GMT
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  

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



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!

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