| Andy Jefferson 2005-08-19, 5:45 pm |
| 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 =E2=80=9Cfalse=E2=
=80=9D 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=
=20
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=
=20
the spec currently says that an embedded instance is "stored as part of the=
=20
containing instance". That's fine too, on its own, but it doesn't distingui=
sh=20
it from a serialized instance, which is also "stored as part of the=20
containing instance" (though in one column). I think we should have a=20
description of an embedded, referring to it being mapped column-by-column=20
(where it is of PC, Object or Interface type) to distinguish it from=20
serialized.
The other detail I feel is lacking from the spec is how the embedded=3D"tru=
e"=20
and <embedded> interrelate. Suppose I have a PC class which has a PC=20
field ...
1. If I specify the PC field as embedded=3D"true" but omit the <embedded>=20
element, this presumably allows the JDO impl to either map the fields of th=
e=20
embedded PC field as it decides (since the user has provided no mapping=20
details), or to require the user to define the <embedded> element.
2. Specifying the <embedded> element, but not specifying the embedded=3D"tr=
ue"=20
will presumably result in the field being embedded (i.e specifying the=20
<embedded> element is effectively setting embedded=3D"true"). The descripti=
on=20
of <embedded> in Ch18 says that the <embedded> specifies the mapping for an=
=20
embedded type. It doesn't say anything about whether the user needs to make=
=20
the type embedded=3D"true" for this element to be used.
3. If I specify the PC field with just an <embedded> element, and the PC to=
be=20
embedded has 10 fields that are persistence-modifier=3D"persistent" but the=
=20
user only specifies 6 of them in the <embedded>, presumably the JDO impl wi=
ll=20
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.
=2D-=20
Andy
|