views:

4371

answers:

3

Hibernate has a handful of methods that, one way or another, takes your object and puts it into the database. What are the differences between them, when to use which, and why isn't there just one intelligent method that knows when to use what?

The methods that I have identified thus far are:

  • save()
  • update()
  • saveOrUpdate()
  • saveOrUpdateCopy()
  • merge()
  • persist()
+3  A: 

Here's my understanding of the methods. Mainly these are based on the API though as I don't use all of these in practice.

saveOrUpdate Calls either save or update depending on some checks. E.g. if no identifier exists, save is called. Otherwise update is called.

save Persists an entity. Will assign an identifier if one doesn't exist. If one does, it's essentially doing an update. Returns the generated ID of the entity.

update Attempts to persist the entity using an existing identifier. If no identifier exists, I believe an exception is thrown.

saveOrUpdateCopy This is deprecated and should no longer be used. Instead there is...

merge Now this is where my knowledge starts to falter. The important thing here is the difference between transient, detached and persistant entities. For more info on the object states, take a look here. With save & update, you are dealing with persistant objects. They are linked to a Session so Hibernate knows what has changed. But when you have a transient object, there is no session involved. In these cases you need to use merge for updates and persist for saviing.

persist As mentioned above, this is used on transient objects. It does not return the generated ID.

Lee Theobald
I'd like to accept this as the answer, but one thing is still unclear: since save() falls back on update(), if such item exists, how does it differ from saveOrUpdate() in practice?
Henrik Paul
Where is it specified, that save would work on detached instances?
jrudolph
If your description of merge/persist only being important on transient objects then this makes a ton of sense and fits with how we use hibernate. Also note a merge often has performance limitations compared to an update as it seems to do extra fetching for integrity checks of some sort.
Martin Dale Lyness
+5  A: 
  • See the Hibernate Forum for a explanation of the subtle differences between persist and save. It looks like the difference is the time the INSERT statement is ultimately executed. Since save does return the identifier, the INSERT statement has to be executed instantly regardless of the state of the transaction (which generally is a bad thing). Persist won't execute any statements outside of the currently running transaction just to assign the identifier. Save/Persist both work on transient instances, ie instances which have no identifier assigned yet and as such are not saved in the DB.

  • Update and Merge both work on detached instances, ie instances which have a corresponding entry in the DB but which are currently not attached to (or managed by) a Session. The difference between them are what happens to the instance which is passed to the function. update tries to reattach the instance, that means that there may be no other instance of the persistent entity attached to the Session right now otherwise a exception is thrown. merge, however, just copies all values to a persistent instance in the Session (which will be loaded if it is not currently loaded). The input object is not changed. So merge is more general than update, but may use more resources.

jrudolph
+1  A: 

Be aware that if you call an update on an detached object, there will always be an update done in the database whether you changed the object or not. If it is not what you want you should use Session.lock() with LockMode.None.

You should call update only if the object was changed outside the scope of your current session (when in detached mode).

bernardn