Hi Andy,

Is it possible to default the value of the <field> serialized attribute to "true" for embedded non-PC types? That would immediately solve our current Collection, Set, and Map issues, without having extra stuff in the metadata file.

The .jdo file specifies the embedded-element, embedded-key, and embedded-value attributes for the relevant fields, so simply changing the defaults would make it all work.

I looked at the spec again and it doesn't look like the serialized attribute should be required, so it would be better if it were defaulted.

The embedded attribute specifies whether the field should be stored as part of the containing instance instead of as its own instance in the datastore. It must be specified or default to "true" for fields of primitive types, wrappers, java.lang, java.math, java.util, collection, map, and array types specified above; and "false" otherwise. While a compliant implementation is permitted to support these types as first class instances in the datastore, the semantics of embedded=”true” imply containment. That is, the embedded instances have no independent existence in the datastore and have no Extent representation.
The semantics of embedded applied to collection, map, and array types applies to the structure of the type, not to the elements, keys, and values. That is, the collection itself is considered separate from its contents. These may separately be specified to be embedded or not, using embedded-element, embedded-key, and embedded-value attributes of the collection, array, and map elements.
The embedded attribute applied to a field of a persistence-capable type is a hint to the implementation to treat the field as if it were a Second Class Object. But this behavior is not further specified and is not portable.



On Jul 14, 2005, at 10:36 AM, Andy Jefferson wrote:

So I think it is a requirement for the Reference Implementation...
To help clarify this for the TCK, we can/should add the "serialized"
attribute to the columns in the metadata that are embedded.

Next nightly build of JPOX will have basic support for fields of 
collections/maps declared as "serialized". This should get around the initial 
schema issues about join tables/columns etc.

Java Persistent Objects - JPOX

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!