[
https://issues.apache.org/jira/browse/OPENJPA-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cefn Hoile updated OPENJPA-1896:
--------------------------------
Description:
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 record.
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 [email protected] 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.
http://bit.ly/hfPjTI
was:
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 record.
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 [email protected] 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.
http://mail-archives.apache.org/mod_mbox/openjpa-users/201011.mbox/%[email protected]%3e
I've changed the link to the mailing list thread above to be something which
Jira's smart formatting doesn't break through incompetent parsing.
So...
http://bit.ly/hfPjTI
...was previously...
http://mail-archives.apache.org/mod_mbox/openjpa-users/201011.mbox/%[email protected]%3e
> OpenJPA cannot store POJOs if a corresponding record already exists
> -------------------------------------------------------------------
>
> Key: OPENJPA-1896
> URL: https://issues.apache.org/jira/browse/OPENJPA-1896
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 2.0.1
> Environment: Eclipse, Sun Java 1.6, Ubuntu Lucid, Guice
> JPAPersistModule, build-time enhance.xml
> Reporter: Cefn Hoile
>
> 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 record.
> 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 [email protected] 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.
> http://bit.ly/hfPjTI
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
