Some members of the Hibernate developer team recently had a heated discussion on the importance of some Session API methods for saving objects. What do you think is more important and popular?

i really prefer long session per application transaction, so i only really use session.save() for new instances.

I have few use cases where i must manage detached instances, and i prefere session.update() than session.saveOrUpdate().

Interesting.
I design my apps as stateless as I can, including "serialization" in the HTML form if needed. So saveOrUpdate has my favors.
Memory is cheap, but fail over is important and platform mutualization too.

+1 (most of my apps doen't require failover, only loadbalancing + sticky session)
BUT
long session pattern has to be well used. Too long session can mean heavy object network so more memory and failover more difficult... so if you need failover... that is a good point

This is very interesting.

We only use save() and update() but we're dealing with mostly detached objects. We could probably get away with saveOrUpdate() but it just feels dirty :D

What about create()?

We just completed our very first J2EE app. This app was strictly a "view" only app so we did not have to use much of the Save or Update methods. We currently use CreateQuery and Find mostly. HOWEVER, the more I read "Hibernate in Action", and with future projects coming our way, I see where we will most definitely use more in future projects.

Im personally not a fan of saveOrUpdate for no reason other then I can't imagine writing an application where it's not perfectly clear whether you're adding a new row to your table or merely updating an existing one. Adding a new row to my DB has to be a very deliberate and explicit action, not something that can happen by mistake ( e.g. forgetting to copy over the primary key between html pages), causing hibernate to mistake the passed object for a new object. ..

In short, using saveOrUpdate makes your code less explicit and more bug prone, IMHO...

Moreover, implemeting your own, explicit version of saveOrUpdate method is a simple matter of writing one if / else statement...I'd much rather do that, then try to remember every time what Hibernate may interpret as a save or update operation...

You can look at it from the other side too though. I have an application where I have a form that is used for both adding new and updating existing objects. I don't care whether the object is new or existing, I just want to insert or update it in the database. saveOrUpdate could probably be renamed to insertOrUpdate, addOrUpdate, or createOrUpdate because you're saving data to the database in both cases. Or, just save, and eliminate the other two methods.

Im glad you brought up that point -- using the same form/jsp page for inserting or updating a record is common, as both operations require all of the same fields. But let me ask you this... let's say you have a simple phone directory app, and an add/update page for phone number with the following fields:

First Name:
Last Name:
Home Phone:

Add/Update Button.


Now, behind the scenes, you also have a surrogate primary key ( from a sequence ) which is the uniqe identifier for your record.Now, I pull up the page of an existing record so the page shows:

First Name: Mike
Last Name: Smith
Phone Number: 555-555-5555

So if the user modified any of the fields, you simply do an update of this record. But what if the user clears out all three fields and types:

First Name: John:
Last name: Wallker
Phone number: 345-344-5555

Is this an insert or an update? Calling saveOrUpdate on hibernate will result in an update -- essentialle eliminating the Mike Smith entry, and replacing him with John Walker...is this what the user intended?

Anyway, just a silly example I guess...but I think it's always better to be explicit. ( you can still resue the same page for both operation, just set a flag which makes clear what is happening...)

I assume so, if you let them modify data to their heart's content. This is more an issue of your UI and validation.

I'm a fan of the saveOrUpdate() to persist after both a Create or Edit command. Allows me to consolidate code and avoid cut-and-paste for validation.

When you have a role based application you must separate inserts from updates based on user rights. It is not convenient but secure. I vote for explicit operation call.

I use Hibernate for web applications.
When a user create a new object he has to fill a form (o a sequence of form, if a wizard-like system is needed, mostly for properties dependence...) and then click save button.
In case of updates I have to load the object, send to the view to let user to modify it and then update.
To me, there's no difference, so I prefer saveOrUpdate. My DAO's follows the same logic.

Often I see that's also very useful (mostly in the Service/Manager layer) to have a method like "loadOrCreate": I think it coul be useful when new objects has to retrieve defaults property values from the database.

Very important, since what web application is not role-based?

I do this by having a Create action available only to the admin role (for example) make a new object, and put it in the session. Edit loads and also puts it in the session. Then validation, and returning for more edits, works on this temp object (new or loaded), which they can saveOrUpdate(). They can only save the object they have, however. This way I can have a nicer UI (no "sorry, start all over" if it doesn't validate), and can secure access.

Just a preference, since I hate to copy-and-paste. I think both ways are fine, and both can be secure if you build them that way.

I hope both techniques will continue to be supported.

If not, everyone will be writing their own wrapper methods (just like we do now for generic count(*) functionality).

Hibernate knows whether the PK is null, so usually we can let it do the work. In a web controller context, the following is very common:

1. Foo foo = findFoo( ... )
2. if( foo == null ) foo = new Foo();
3. foo.setBar( ... );
4. saveOrUpdate( foo );

IMHO the use of creational or "must exist" or "security" constraints is best employed at level 1 or 2 in the application domain. Then by the time you want to persist an object, you dont care whether it was originally loaded by a query or created as a transient.