openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cefn Hoile (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1896) OpenJPA cannot store POJOs if a corresponding record already exists
Date Tue, 21 Dec 2010 10:39:02 GMT


Cefn Hoile commented on OPENJPA-1896:

Sorry to let you down, Rick. I can't easily verify the patch. I no longer have a codebase
incorporating OpenJPA as I switched to Hibernate. This bug just seemed too major to me, and
made me wonder what else I would discover if I relied on OpenJPA.

I appreciate the work you've put in, and I hope it helps supporting other OpenJPA users who
want to use POJOs with natural keys as the project gets wider adoption. I like a lot of the
features which OpenJPA adds on top of JPA, but standards conformance is more important for
the future of our project (switching easily between persistence frameworks). 

Focusing just on JPA functionality I found the OpenJPA enhancement process really complex
and likely to introduce issues in deployment, (Hibernate just worked). However, this merge
bug was the clincher because of the domain we're working on.

> OpenJPA cannot store POJOs if a corresponding record already exists
> -------------------------------------------------------------------
>                 Key: OPENJPA-1896
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 2.0.1
>         Environment: Eclipse, Sun Java 1.6, Ubuntu Lucid, Guice JPAPersistModule, build-time
>            Reporter: Cefn Hoile
>            Assignee: Rick Curtis
>         Attachments: openjpa-1896.jar
> If a POJO is created using a java constructor, merge() cannot store the newly constructed
object's data if this means updating a pre-existing record with a matching identity.
> This is a major bug since it means applications where the objects have a natural key
cannot use OpenJPA. In my case the example was a filesystem; each crawl of the filesystem
generates its own data objects with file path as the natural key. These objects then need
to be stored into the database. Previous crawls may have encountered the same files, and the
merge operation should cause the latest data from the POJO to be stored in the pre-existing
> Instead, any attempt to execute either merge() or persist() on an independently constructed
object with a matching record identity in the database triggers the same error in the database
layer, since OpenJPA attempts to execute an insert for a pre-existing primary key, throwing...
> org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: duplicate key value violates
unique constraint "file_pkey" {prepstmnt 32879825 INSERT INTO file (locationString, location,
version, folder) VALUES (?, ?, ?, ?)  [params=?, ?, ?, ?]} [code=0, state=23505]
> From discussion with Rick Curtis on the list, this is because
the version field on a POJO which is unmanaged is not yet set. 
> An ASSUMPTION seems to be made that no such record exists in the database already since
it wasn't loaded from the database in the first place, so a persist is attempted. Instead,
I recommend the database is QUERIED TO FIND OUT if such a record already exists, and the version
field is set correspondingly before attempting the merge() 
> Here is the corresponding thread containing Ricks comments and links to an example in
Github which can recreate the problem.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message