Hi Markus,
My understanding is that putting @Id on a relationship field is not
supported by version 1.0 of the JPA specification. If you look at
section 2.1.4 of the specification it is quite specific about only
allowing primary keys to be composed of primitive types:
"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."
I have heard some rumors that this is under discussion for the next
version of the specification, but to be honest I am not sure. I suggest
sending a request to the expert group. I am not sure what the exact
email address is, but perhaps someone on this forum will be nice enough
to post it.
-Tom
Markus KARG wrote:
> I think I found a bug in TopLink and want to discuss with you before
> hastily reporting it officially.
>
> There is one entity that has a compound key made up of two fields, and
> it has a sub-entity using @Inheritance(strategy = JOINED). I can
> insert new rows using the super class directly, but when I want to use
> the sub-class, TopLink produces a SQL INSERT statement that just fills
> one of the compound key's fields -- and forgets the other one!
> Certainly the database server complains about that.
>
> In fact, I'd like to know whether that is a real bug or whether I am
> doing something wrong (in that case, please tell me what I am doing
> wrong and where in the JPA specification that is told).
>
> Here is the interesting part of the source code:
>
> @Entity
> @Inheritance(strategy = JOINED)
> public abstract class TheSuperClass {
>
> @Id
> @ManyToOne
> private Invoice invoice; // TheSuperClass actually is part of an
> Invoice
>
> @Id
> private int position; // Inside of the Invoice, we identify
> multiple instances using this int
>
> ...
>
> @Entity
> public final class TheSubClass extends TheSuperClass { // TheSubClass
> is a specialization of TheSuperClass
>
> (there is no additional code in this class, since it I stripped away
> everything for this small sample)
>
>
> I am totally stuck with that problem. Please help me. :-)
>
> Thanks
> Markus
>