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
