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