Return-Path: 
 <jdo-dev-return-755-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org>
Delivered-To: apmail-db-jdo-dev-archive@www.apache.org
Received: (qmail 71296 invoked from network); 17 Jul 2005 08:23:40 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Jul 2005 08:23:40 -0000
Received: (qmail 81335 invoked by uid 500); 17 Jul 2005 08:23:40 -0000
Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:jdo-dev-help@db.apache.org>
List-Unsubscribe: <mailto:jdo-dev-unsubscribe@db.apache.org>
List-Post: <mailto:jdo-dev@db.apache.org>
List-Id: <jdo-dev.db.apache.org>
Reply-To: jdo-dev@db.apache.org
Delivered-To: mailing list jdo-dev@db.apache.org
Received: (qmail 81322 invoked by uid 99); 17 Jul 2005 08:23:40 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Jul 2005 01:23:40 -0700
X-ASF-Spam-Status: No, hits=1.7 required=10.0
	tests=RCVD_IN_NJABL_DUL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [81.174.133.99] (HELO roobarb.ajsoft.net) (81.174.133.99)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Jul 2005 01:23:36 -0700
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by roobarb.ajsoft.net (Postfix) with ESMTP id 7086B1111F;
	Sun, 17 Jul 2005 09:23:31 +0100 (BST)
From: Andy Jefferson <andy@jpox.org>
To: jdo-dev@db.apache.org, JDO Expert Group <jdo-experts-ext@Sun.COM>
Subject: Re: Embedded collections of non-PC objects
Date: Sun, 17 Jul 2005 09:23:29 +0100
User-Agent: KMail/1.7.2
References: <42D2A542.60300@spree.de> <200507150806.03090.andy@jpox.org>
 <2CA34DD5-54A0-4351-931A-9E0A4D358E93@Sun.COM>
In-Reply-To: <2CA34DD5-54A0-4351-931A-9E0A4D358E93@Sun.COM>
Organization: JPOX
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507170923.30350.andy@jpox.org>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Hi Craig,

thanks for your reply and your insights.

> > Example 1 : Collection of BigDecimal
> > 1. Basic collection
> > <field name="myfield">
> >     <collection element-type="java.math.BigDecimal"/>
> >     <join/>
> > </field>
> > This creates 2 tables - 1 for the class owning "myfield", and 1
> > join table to
> > contain the elements. If <join> is omitted then an error should be
> > thrown
> > (though i'm not sure if JPOX currently flags this up)
>
> The join element has no defaults, so this is not sufficient to
> describe the mapping. You need at least a column attribute naming the
> join column. And you need to name the column in the join table to map
> the BigDecimal values to. So,
>
> <field name="myfield" column="VALUES" table="MYFIELD_TABLE">
>      <collection element-type="java.math.BigDecimal"/>
>      <join column="JOIN_COLUMN"/>
> </field>

I don't necessarily agree here. We have to qualify the statement with the 
following
New schema : The JDO impl is perfectly capable of providing default namings 
for columns and perfectly capable of choosing the join columns ... since it 
has the (PK) columns in the main table. It provides default namings for 
columns in other situations. 
Existing schema : The user should specify the columns and table as you stated.


> > embedded-element has no effect with this example because the element
> > (BigDecimal) is already embedded (in the join table), and has no
> > way of not being embedded.
>
> I'd say that serialized implies embedded-element (and vice-versa,
> which is why I'm now questioning the value of serialized as an
> attribute).

OK. That wasn't my interpretation. I see 2 levels of embedded. We have 
"embedded" at field level, and "embedded-element" (or -key, -value) at 
collection/map level. I see embedded-element/key/value as saying that we want 
to embed the elements/keys/values in a join table (like in the example 9 in 
the spec), and embedded (at field level) saying that we want to embed the 
whole collection/map into the main table.


> > 3. Embedded element
> > <field name="myfield">
> >     <collection element-type="MyElement" embedded-element="true"/>
> >     <join/>
> > </field>
> > This creates 3 tables - 1 for the class owning "myfield", and 1
> > join table
> > containing the elements (columns aligned with the fields of the PC
> > element).
>
> Since it's embedded, I think there is only one table that contains
> all the fields in the class, including the Collection of MyElement.
>
> You can't map the columns of an embedded Collection of PC elements
> because you would need one column for each field in each PC, which is
> a variable number of columns. And tables have a fixed number of
> columns. So the mapping has to either serialize the Collection and
> store it into a BLOB column or use another table. For embedded
> collection,

As my comment above, I didn't interpret (embedded-element/key/value) like 
this. I'll try to justify this, with a map this time :-) ...
1. We have a map with embedded-key=false, embedded-value=false. This ends up 
with a main table, and a join table, and optionally (if the keys/values are 
PC), tables for key and value. No disagreement there.

2. We have a map with embedded-key=true, embedded-value=false. How would you 
store these ? Would you have a BLOB column for the map keys, and have the map 
values stored off in their own table (since they aren't embedded) ? This 
would make managing the map a bit tricky for the JDO impl (to say the 
least!). I would store the keys as embedded into the join table (as per 
example 9 in the spec - multiple columns in the join table lining up with the 
fields in the key), and have the values in their own table (if PC) with a FK 
from the join table. This makes it simple for the JDO impl to manage the map 
since the keys and values are stored in the join table.

3. We have a map with embedded-key=true, embedded-value=true. How would you 
store this ? Would you store them as a single BLOB column in the main table. 
I would store the key AND value in the join table (as per example 9 in the 
spec - so we gain columns for key, and columns for value in the join table).

As for your point above about variable number of columns, well example 9 in 
the spec is just this case. It embeds the element of a collection into a join 
table. This is "embedded" because the elements are not stored as FCO's - they 
are embedded into the join table (which is effectively a secondary table 
owned by the main table - and which represents the collection).

Now if the user specifies <field embedded="true"> then I would expect to have 
to store the whole collection/map as a single BLOB column (like serialized, 
so why do we have a serialized attribute too ?)

I'd welcome any clarification from the people in the know who spent a lot of 
time designing these levels of specification, and from the JDO vendors that 
have supported such embedding for some time on what we interpret these 
attributes as.

> It's been on my to-do list for the specification for a while to add
> mapping for arrays, lists, sets, and maps to Chapter 15. This might
> be the time to actually do it.

That would be great. The spec covers many many situations and the metadata is 
largely intuitive as to what people specify, but I feel we're missing 
clarification on this one part.


Thanks!
-- 
Andy
Java Persistent Objects - JPOX