[
https://issues.apache.org/jira/browse/OPENJPA-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Zowalla resolved OPENJPA-1652.
--------------------------------------
Resolution: Won't Fix
Closing as obsolete during backlog cleanup: the reporter's problem was solved
with persist(), and the request is only a vague wish to copy EclipseLink
annotations, with no concrete OpenJPA design. Please reopen if this still
happens with OpenJPA 4.x.
> implement @ReturnUpdate for Sequences
> -------------------------------------
>
> Key: OPENJPA-1652
> URL: https://issues.apache.org/jira/browse/OPENJPA-1652
> Project: OpenJPA
> Issue Type: New Feature
> Components: jpa
> Affects Versions: 1.2.2
> Environment: java 6
> Reporter: Diddle
> Priority: Minor
>
> Most other jpa implement merge to be a stand in for persist. some use
> @ReturnUpdate and even @ReturnInsert (OpenLink, EclipseLink) as an option so
> you can tune this behaviour and save some overhead when not required.
> It took me hours to work out what the problem was because I'm used to using
> it this way. I spent a long time devising work arounds and trying to
> interpret the openjpa error messages. I was going to call nextval and tried
> to update the entity but commit failed. I considered writing stored
> procedures to achieve this. I tried EclipseLink but these annotations don't
> work on primary keys. You can imagine my relief when I tried persist and it
> worked.
> It's a little more messy since I have to test if I have supplied a not null
> parameter to persist or merge, or I have to implement different methods for
> insert and update duplicating much code. It would be handy. While I was
> debugging I could see the value was available. Why not update the entity
> since the JPA already knows this field is a Sequence.
> It's just an idea, but it would be handy.
> If it's a Sequence and the call in merge, update the entity with the primary
> key.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
