Skip to main content

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

  • From: Steve Ebersole <steve.ebersole@...>
  • To: jsr338-experts@...
  • Cc: Oliver Gierke <ogierke@...>, Linda DeMichiel <linda.demichiel@...>
  • Subject: [jpa-spec users] [jsr338-experts] Re: Clarification of PersistenceUnitUtils.getIdentifier(…)
  • Date: Fri, 11 Jan 2013 10:23:53 -0600
  • List-id: <jsr338-experts.jpa-spec.java.net>

Granted that this is an "implementation detail", but the problem here is that returning null in this case effectively requires bytecode enhancement. As Hibernate does not work on bytecode enhancement we have to simply return the entity instance's current attribute state.

So as I said, I realize that the above is an "implementation detail", but given that the spec specifically does not require bytecode enhancement I don't see how we can then effectively require bytecode enhancement

On Thu 10 Jan 2013 06:16:27 PM CST, Linda DeMichiel wrote:
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



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

Oliver Gierke 01/10/2013

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

Linda DeMichiel 01/11/2013

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

Steve Ebersole 01/11/2013
 
 
Close
loading
Please Confirm
Close