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: Embedded collections of non-PC objects
Date Thu, 14 Jul 2005 19:22:50 GMT
Hi Craig,

> 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.

Anything is possible ...

> 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>

Well this does beg the question, where is the difference between "serialized" 
and "embedded" at <field> level then ?
If I specify <field embedded="true">  for a collection, is this the same as 
<field serialized="true"> for the collection ?  "serialized" doesn't have a 
description in 18.13 btw.

Personally I would expect a Collection<String> or Map<String, String> to 
default to having the elements queryable, and embedding them (by default) is 
not going to give me that. Perhaps I just disagree with the spec on this 
issue :-)

Perhaps some examples would be beneficial ? (in the spec). Not that I'm trying 
to increase your workload :-0. I see one example of "embedded" and that is 
<embedded> defining fine details of how to embed an object (which is what I 
would expect to use this keyword for anyway), and which seems a long way from 
what we're talking about here. If I'm not understanding this then you can bet 
SUN's vast bank balance that users will have a hard time working it out, and 
I'm not going to spend my spare time explaining it to them


-- 
Andy
Java Persistent Objects - JPOX

Mime
View raw message