Can I override generated IDs?

I'm using JPA 1, Hibernate and Oracle 10.2.0 and my entities are defined like this:

@Entity
@Table(name="TERMS")
public class Term implements Serializable {
    @Id
    @GenericGenerator(name = "generator", strategy = "guid", parameters = {})
    @GeneratedValue(generator = "generator")
    @Column(name="TERM_ID")
    private String termId;
}

I have a situation where an XML representation of the Entity (and child entities) will be开发者_如何学JAVA coming in through a web service to update/replace existing ones. My thought was to just delete the old ones and re-create it from the incoming XML.

However, doing a persist when my entities having existing IDs seem to make Hibernate very angry. So is this actually possible or is it better to avoid deleting them and just trying to do it with merge?

Angriness from hibernate:

org.hibernate.PersistentObjectException: detached entity passed to persist: com.idbs.omics.catalog.entity.Term

Thanks

---

My thought was to just delete the old ones and re-create it from the incoming XML. However, doing a persist when my entities having existing IDs seem to make Hibernate very angry..

Indeed, you cannot assign an Id when it is supposed to be generated, at least not with Hibernate that won't consider the entity as new but as detached (the JPA specification is a bit blurry on the exact rules in this case but that's how Hibernate behaves, see 5.1.4.5. Assigned identifiers for more hints).

So is this actually possible or is it better to avoid deleting them and just trying to do it with merge?

To make the delete/insert possible for the web service use case, you'd have to either:

• not assign the id ~or~
• use a special version of the entity without a generated identifier ~or~
• use bulk operations(?)

The alternative if you're actually updating detached entities would be indeed to use a merge (but have a look at these previous questions just in case).

Which approach is better? I don't know, it think it depends on your needs. The later seems more natural if you're updating existing entities. With the former, you'd really get "new" entities (including a new value for the optimistic locking column). Depending on the exact implementation of the process, performances might also vary. And, by the way, what about concurrency (just to mention it, I'm not really expecting an answer)?

---

You can use EntityManager.merge to save an updated version of the entity. Be aware that this returns another object than the one you pass to it, because it basically fetches the entity from the database, updates the persistent properties from the object you pass and saves the persistent object.

See http://blog.xebia.com/2009/03/23/jpa-implementation-patterns-saving-detached-entities/ for more information on this problem.