Hi Craig, > I've enhanced the spec as follows: > 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” for > other types including persistence-capable types, interface types and > the Object type.
Yes, this defines how the user specifies that a field is to be embedded. No problems there. > Embedded is different from serialized. I've proposed a spec change to > that effect. I think that people would be surprised to find embedded > objects were actually serialized in this case, as embedded PC types > like Address are handled very differently elsewhere in the spec > (using the <embedded> element). Yes, I'm aware that there are 2 ways we can do it. All my point was is that the spec currently says that an embedded instance is "stored as part of the containing instance". That's fine too, on its own, but it doesn't distinguish it from a serialized instance, which is also "stored as part of the containing instance" (though in one column). I think we should have a description of an embedded, referring to it being mapped column-by-column (where it is of PC, Object or Interface type) to distinguish it from serialized. The other detail I feel is lacking from the spec is how the embedded="true" and <embedded> interrelate. Suppose I have a PC class which has a PC field ... 1. If I specify the PC field as embedded="true" but omit the <embedded> element, this presumably allows the JDO impl to either map the fields of the embedded PC field as it decides (since the user has provided no mapping details), or to require the user to define the <embedded> element. 2. Specifying the <embedded> element, but not specifying the embedded="true" will presumably result in the field being embedded (i.e specifying the <embedded> element is effectively setting embedded="true"). The description of <embedded> in Ch18 says that the <embedded> specifies the mapping for an embedded type. It doesn't say anything about whether the user needs to make the type embedded="true" for this element to be used. 3. If I specify the PC field with just an <embedded> element, and the PC to be embedded has 10 fields that are persistence-modifier="persistent" but the user only specifies 6 of them in the <embedded>, presumably the JDO impl will be expected to map the others. > The spec doesn't call out whether support for embedded Object or > embedded interfaces is required. I don't think it should be required, > but then we need a way to identify an implementation as supporting > this feature. Something like > javax.jdo.options.mapping.EmbeddedInterface and ...EmbeddedObject. Agreed. -- Andy
