db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Support java.lang.Object as FCO
Date Fri, 19 Aug 2005 15:35:33 GMT
Hi Andy,

Thanks for your thoughtful insights here.

It appears we are in sync for supporting field types of Object as  
FCO, and now we're discussing support for Object as SCO (embedded).

On Aug 17, 2005, at 11:26 PM, Andy Jefferson wrote:

> Hi Craig,
>>> Well we interpret all types as serialized="false", but in section
>>> 18.14 of the
>>> spec "java.lang" types (which Object is) are to be  
>>> embedded="true" by
>>> default. So we interpret this as serialising the Object into the
>>> table of the
>>> class, into a BLOB column.
>> I tried to be more explicit about this in the Proposed Final Draft,
>> to say that embedded="true" doesn't mean serialized but embedded
>> column by column. Just like embedded PC instances.
> OK, but the issue here is whether "java.lang.Object" defaults to
> embedded="true" or embedded="false". The wording at the start of  
> the section
> 18.14 Embedded can be interpreted 2 ways. That java.lang.Object is  
> embedded
> by default, or it isn't.

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.
> Looking at some of the JDO1 books, Object is *not* embedded by  
> default, so
> I've updated JPOX to reflect this (in last nights build -  
> 18/08/2005). This
> gets around the immediate issue that Michelle raised.

This is consistent with what the spec intended.
> When we have an Object field that is marked as embedded="true" JPOX  
> will
> currently serialise it into a single column - since we don't support
> embedding it column by column into the owning table.

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

> I looked at the PFD and
> couldn't decide if this is valid or not. You're saying that we  
> should embed
> the Object column-by-column.
> We have 2 situations
> <field name="myObjectField" embedded="true"/>
> This one we treat as serialised currently since no embedded  
> definition is
> available
> <field name="myObjectField">
>     <embedded>
>         ...
>     </embedded>
> </field>
> This we do not support since the Object field could have multiple
> "implementations" stored there, so the fields will vary. For the  
> same reason
> we don't support the same situations with interface fields

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.

> -- 
> Andy

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message