Thought everyone might want to see this particular item ...
This could really change how we determine what "attributes" are
mappable, and may require for the first time that we keep per-class
information above and beyond the annotations.
-------- Original Message --------
One of the complexities we have in the current persistence
spec results from the high degree of flexibility that we
provide for the intermixture of access=PROPERTY and
access=FIELD within the same inheritance hierarchy.
Mike and I are both concerned with this as a going-out
position for the first release of this specification.
We therefore propose that we simplify to have a single
access type per class hierarchy. In practice, this
itself would already give more flexibility than the
large majority of applications use or need--which
is more typically a single access type per application.
Another significant benefit of this simplification would be
that it would provide simpler and more flexible means to let
the developer specify the access type, and would not require
developers who preferred access=FIELD to need to specify it
per class (or in XML).
Currently we require that when a particular access type is
used the developer must annotate either fields or properties
with the mapping annotations (depending on whether accessType
is field or property).
We propose that we use the placement of the required annotation
for the primary key (@Id, @EmbeddedId) as determining the
access type (and retain the current rule about placement
of mapping annotations).
This would still leave open for future releases the ability
to allow an access type to be explicitly specified on a
per-class basis--either in annotations or in XML.
To summarize, the proposed simplification is:
Annotation by @Id would determine the access type used for
a class hierarchy.
When @IdClass is used (which is applied to entity class rather
than field/property), the @Id annotation must be used to
annotate the entity fields/properties that correspond to
the @IdClass.
thanks!
Linda
|
