db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@jpox.org>
Subject Re: Support java.lang.Object as FCO
Date Fri, 19 Aug 2005 19:54:04 GMT
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 

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.



View raw message