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. <spec> 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. </spec> Thanks, Craig On Jul 14, 2005, at 10:36 AM, Andy Jefferson wrote:
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! |
smime.p7s
Description: S/MIME cryptographic signature