users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: Clarification of PersistenceUnitUtils.getIdentifier(…)

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Thu, 10 Jan 2013 16:16:27 -0800

Yes, this is a hole in the spec from JPA 2.0.

I'd like to get opinions from the group as to how we should close it, especially
if you have knowledge of developers depending on the current behaviors of your respective
implementations.

thanks,

-Linda


On 1/10/2013 1:18 AM, Oliver Gierke wrote:
> Hi all,
>
> the JavaDoc of PersistenceUnitUtils.getIdentifier(…) states the following:
>
>> Return the id of the entity.
>> A generated id is not guaranteed to be available until after
>> the database insert has occurred.
>> Returns null if the entity does not yet have an id.
>
> I had a discussion with Romain Manni-Bucau (involved with the Apache Foundation and OpenJPA, AFAIK) about the detailed semantics of this in case you are using primitive identifiers like this:
>
> @Entity
> class Person {
>
> @Id long id;
> }
>
> Romain argued that the spec defines that getIdentifier(…) would/should return null for a new Person(), as it theoretically did not get any ID assigned yet but effectively has a value. Personally, I didn't read this meaning into the specification of the method. This impression seems to be backed by the fact that I discovered different persistence providers handling this differently:
>
> - OpenJPA 2.2.0 -> returns null for new Person(), but a non-null value once I called em.persist(…)
> - Hibernate 3.10.0 -> return a non-null value even for new Person()
>
> What is the actual intent of the method? As it is right now, one cannot use the method to determine whether the entity already had been persisted reliably across persistence providers. What do the TCK tests of this method look like?
>
> Regards,
> Ollie
>