openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leake, Stephen" <>
Subject Re: Bug in Enhancer?
Date Thu, 22 May 2008 09:11:24 GMT
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.








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



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 <>



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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message