Issue Details (XML | Word | Printable)

Key: GLASSFISH-4940
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: tware
Reporter: mkarg
Votes: 1
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

Generated Primary Key not available in PostPersist

Created: 27/Apr/08 08:00 AM   Updated: 06/Oct/09 09:00 AM   Resolved: 06/Oct/09 09:00 AM
Component/s: entity-persistence
Affects Version/s: V3
Fix Version/s: V3

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive Issue4940.zip (6 kB) 30/Apr/08 07:47 AM - mkarg

Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,940
Status Whiteboard:

as911-na

Tags:
Participants: gyorke, kumara, Mitesh Meswani, mkarg, pkrogh, sanandal and tware


 Description  « Hide

According to the EJB 3.0 Persistence specification, a generated primary key must
be available in @PostPersist methods. While this works pretty well as long as
the primary key is @Id, that is not working when the primary key is @EmbeddedId:
No instance of the primary key class is created.

I did not find a section of the specification that makes a distinction in this
situation between @Id and @EmbeddedId, so for me it looks like a violation of
the specification.



gyorke added a comment - 28/Apr/08 06:23 AM

@GeneratedValue is used to specify a field that should be populated with a PK
value. It is not used to create an instance of an Embedded class. In the vast
majority of cases TopLink could not create the correct EmbeddedPK instance as
there would be other user provided values that combined produced the EmbeddedPK.

Developers should ensure they are creating an instance of the EmbeddedPK and
placing it within the entity prior to calling persist. Any values within the
EmbeddedPK (marked with @GeneratedValue)will be assigned a PK value.


mkarg added a comment - 28/Apr/08 11:58 AM

I understand that the PK must be created by the programmer, but once you do
that, TopLink no more creates the correct SQL:

Using @Id + @GeneratedValued(strategy = IDENTITY) (in entity), TopLink correctly
excludes the autogenerated column's name, so the database server provides a value:

INSERT INTO dba.CostDescription (DESCRIPTION) VALUES

Using @EmbeddedId + @GeneratedValue(strategy = IDENTITY) (in @Embeddedable),
TopLink now includes the autogenerated column's name and a value of zero, so the
database server just accepts that value instead of generating a value. As a
result, you end up with duplicate PK exception:

INSERT INTO dba.CostDescription (DESCRIPTION, ID) VALUES (?, ?)

(ID is the autogenerated column)

I can proof this with a small sample I have written, if you do not believe.

So this IS a bug in TopLink, and since I cannot work around it, it is a severe one.


mkarg added a comment - 30/Apr/08 07:47 AM

Created an attachment (id=1479)
Sample code that demonstrates the bug described in my last comment


mkarg added a comment - 06/May/08 01:11 AM

As I just tried out, there is a related bug when using @EmbeddedId together with
@TableGenerator in the PK class:

The created SQL is correct

INSERT INTO MYENTITY (DESCRIPTION, ID) VALUES (?, ?)

but the value provided for the ID column always is zero, so the database
complains about duplicate PK values.


mkarg added a comment - 06/May/08 01:13 AM
      • Issue 4940 has been confirmed by votes. ***

mkarg added a comment - 08/May/08 09:33 AM

Just for curiosity I have replaced the single int field in the PK class yb and
Integer field. In that case, the column is not added, so the INSERT works pretty
well. But still the autogenerated value is not loaded back into the instance
marked as @EmbeddedId so it is not available in @PostPersists.

Also just for curiosity I asked a friend to run the same program on OpenJPA.
With int, it crashs completely. With Integer it works pretty well. Seems all JPA
implementations have problems with @GeneratedValue in @EmbeddedId.


Mitesh Meswani added a comment - 19/Sep/08 05:59 PM

Will not be fixed for V2.1


sanandal added a comment - 11/Jan/09 07:01 AM

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."


mkarg added a comment - 27/Apr/09 11:33 PM

Increased priority to P2 according to
https://glassfish.dev.java.net/public/IssueTrackerPriority.html as this is a
violation of the JPA specification.


kumara added a comment - 03/Oct/09 02:40 PM

tware: Can you please evaluate whether this issue applies to GlassFish v3/EclipseLink 2.0?


pkrogh added a comment - 06/Oct/09 09:00 AM

EclipseLink uses a model that is similar to this in it's nightly testing.

I can confirm that the situation outlined here in this bug works in
EclipseLink, and therefore V3.