db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: Thoughts about JDO 2.1 Annotation
Date Wed, 17 Jan 2007 01:40:44 GMT
> @Serialized is a valid annotation to add but not for what you're 
> suggesting.
> It should serialise the whole field. If the field is not a container this
> makes no difference but it does for containers (maps/collections/arrays). 
> If
> the field is a collection then the whole collection would be serialised 
> with
> this annotations. This is different to serialising the element only. Best
> visualised with the case (with an RDBMS) and you want a join table and you
> have a List and want to serialise the element into one column of the join
> table. This is where @Element(serialized="true") is used - so the join 
> table
> has 3 columns ... an FK back to the owner, a List order, and a serialised
> element. Similarly for Maps ... @Serialized would serialise the map as a
> whole, whereas @Key(serialized="true")/@Value(serialized="true") would
> serialise the key/value into any join table. The distinction is important.

Actually, this is more or less what I expected.
i.e. @Serialized is equivalent to @Field(serialized="true").

> I'm against the @Index/@Unique on an array/collection/map field implying
> things regarding indexing the element/key/value. Just doesn't work for 
> maps
> and I don't like the assumptions that the JPA spec makes.
> I'm also against having an @Dependent annotation since maps have 2 
> components,
> and JPA falls apart on this one too [Its @Cascade applies to Value only, 
> so
> what happens when a key needs cascading ? undefined!]

OK. That makes sense.

@Embedded (and maybe also @Transient , @EagerFetch) for fields / methods
as well as @EmbeddedOnly for types should still be considered.


View raw message