Hi Albert,
Thanks for responding, but after having read the extract of the JPA spec you posted, I’m
not convinced that what I’m trying to do is a violation of the JPA spec.
My getters and setters conform to the spec. What I’m doing differently is storing the field
data into a collection object but JPA shouldn’t need to be aware of where the field data
is actually being stored.
The extract you posted refers to collections but this is for the case where the persistent
property is itself a collection (typically for a many to one relationship) and I’m not sure
this applies.
Stephen,
It looks like you are "multiplexing" multiple persistence properties into a
single collection type. I believe this is at least violating to the
following JPA spec:
---------------------------------------
2.1.1 Persistent Fields and Properties
....
It is required that the entity class follow the method signature conventions
for JavaBeans read/write properties (as defined by the JavaBeans
Introspector class) for persistent properties when persistent properties are
used.
In this case, for every persistent property property of type T of the
entity, there is a getter method, getProperty, and setter method
setProperty. For boolean properties, isProperty is an alternative name for
the getter method.[3]
For single-valued persistent properties, these method signatures are:
� T getProperty()
� void setProperty(T t)
Collection-valued persistent fields and properties must be defined in terms
of one of the following collection-valued interfaces regardless of whether
the entity class otherwise adheres to the JavaBeans method conventions noted
above and whether field or property-based access is used:
java.util.Collection, java.util.Set, java.util.List[4], java.util.Map.[5]
For collection-valued persistent properties, type T must be one of these
collection interface types in the method signatures above. Generic variants
of these collection types may also be used (for example, Set<Order>).
2.1.4 Primary Keys and Entity Identity
A simple (i.e., non-composite) primary key must correspond to a single
persistent field or property of the entity class. The Id annotation is used
to denote a simple primary key. See section 9.1.8.
A composite primary key must correspond to either a single persistent field
or property or to a set of such fields or properties as described below. A
primary key class must be defined to represent a composite primary key.
Composite primary keys typically arise when mapping from legacy databases
when the
database key is comprised of several columns. The EmbeddedId and IdClass
annotations are used to denote composite primary keys. See sections 9.1.14
and 9.1.15.
The primary key (or field or property of a composite primary key) should be
one of the following types:
any Java primitive type; any primitive wrapper type; java.lang.String;
java.util.Date; java.sql.Date. In general, however, approximate numeric
types (e.g., floating point types) should never be used in primary keys.
Entities whose primary keys use types other than these will not be portable.
If generated primary keys are used, only integral types will be portable. If
java.util.Date is used as a primary key field or property, the temporal type
should be specified as DATE.
---------------------------------------
Hope this help.
Albert Lee.
On Mon, May 19, 2008 at 8:25 AM, Leake, Stephen <stephenleake@fairisaac.com>
wrote:
> If I have the following class the enhancer will enhance it correctly:
This email and any files transmitted with it are confidential, proprietary
and intended solely for the individual or entity to whom they are addressed.
If you have received this email in error please delete it immediately.
|