I've been reading through the forums, but didn't find anything related to the issue I would like to discuss...

In my application, which uses Hibernate 2.1.7, there are several ocassions where I need to save only the subset of a class. For example, imagine I have a User class, where apart from the usual data as name, address, etc., I have some fields with extra information about last date access, last IP used, etc.

This brings two possibilities for updating:

1) Only extra fields need to be updated, as a matter of some kind of auditing for example.

2) Only the "usual" fields need to be updated, as a matter of any user updating his profile (User class), for example.

So the problem I'm facing is about two different partial updates of the User object. I've been reading the documentation and the forums, but only found a post which suggests that a custom persister should be implemented. On the other way, maybe the use of Hibernate 3 and <sql-update> new feature could help, but I don't know if several different updates can be defined.

Can anyone please help me in this issue? I know Hibernate as an ORM is row-based, but in my opinion my post is a common issue in any web application, as always web forms do not have the complete information for the object, don't they?

Or maybe I have to load previously the object being updated, copy the properties that have been changed in my web form and then persist it again, everything in the same session... But isn't this a heavy approach with a lot of work?

Looking forward to hearing your comments ;-)

would dynamic-insert / dynamic-update work for you ?

No, it doesn't solve the problem...

As you know, dynamic-update only generates SET clauses for only those fields who have changed (dirty fields). To succeed, it previously makes a SELECT (through select-before-update="true") and then compares every field's value to see if they have changed. So in my case, the "extra" fields, for example, will come to NULL, so Hibernate thinks they have changed, and then they get changed and the information stored is lost.

So it does not serve to my objective at all...

then custom persister is probably for you

Umm, a custom persister?

But is my problem so strange that it must have a particular solution based on implementing a custom persister?

Taking a look at iBatis I have found this can be done:

<update id="updatePerson" parameterClass="examples.domain.Person">
UPDATE PERSON
SET PER_FIRST_NAME = #firstName#,
PER_LAST_NAME = #lastName#, PER_BIRTH_DATE = #birthDate#,
PER_WEIGHT_KG = #weightInKilograms#,
PER_HEIGHT_M = #heightInMeters#
WHERE PER_ID = #id#
</update>

This allows the developer to define particular SQL CUD statements based on specific parameters that are taken from the fields of a class.

Can this be done in Hibernate? This will solve my problem inmediately...

i can see the reason for it, but you are the first i remember to ask for that feature.

and no we dont have that feature at the moment.

but we do have batchupdate in H3 that might help you since it allows you to execute a hql driven update.

check it out and see if it helps you.

if not then explain your usecase and put it in as a request for improvement and lets see...

/max

Yes, I'm a little surprised that no one has faced this problem yet...

For me it's hard to think that all the applications made with Hibernate always update the whole object, but who knows...

Just to make some more reflexions about this issue...

What I am trying to achieve is to polymorphicly update objects. I mean, just pass an object as an argument to a generic saveOrUpdate method, instead of having to pass one argument per modified field. To clarify:

a) Use polymorphic behaviour, where all the object is passed as an argument to generic load, saveOrUpdate, delete, loadCollection methods. Here is where my problem arises.

b) Use particular methods for the needs of every specific object, i.e. pass as many arguments as fields must be updated, for example. So inside the method, the object is retrieved, setted the modified fields, and saved again.

So from your answers I deduce that the second approach is mostly used by Hibernate users.

Am I right or wrong?

...but now rereading what you said about dynamic-update/dynamic-insert....you dont need to use select-for-update, but you need to get the object loaded.

/max

Yes, but it was easier using that feature...

What about my last reflexion? What do you think?

I really appreciate your comments ;-)

no people send the object to the other side, change it, send it back and then call saveOrUpdate. Then hibernate will do its thing - and if you enable dynamic-update/dynamic-insert it will execute "minimal" sql.....

and that is as close to a as I think possible.

how would you do A with the ibatis approach you mentioned ? you would need to do B and then call the proper update....

/max

Sorry, but didn't quite understand your comments...

What do you mean by "no people send the object to the other side, change it, send it back and then call saveOrUpdate"? From the best of my knowledge, a typical lifecycle for an object using an ORM could be:

1) DAO loads the object and returns it
2) BO (Business Logic Object) collects the object from the DAO and returns it to the upper layer
3) For example, JSF managed bean collects the object from the BO (or maybe through a delgate) and then renders it as a form
4) The user enters values for the object through a web form
5) Following the example, JSF updates the model, i.e. updates fields in the object inside our JSF managed bean
6) An updte call to the delegate or directly to the BO, passsing the updated object as the argument
7) The BO layer gets the object and invokes the DAO using again the object as the parameter
8) Finally the DAO calls the update method in some way like this:

public void saveOrUpdate(Object object)
{
// Suppose we are using Spring.
this.getHibernateTemplate().saveOrUpdate(object);
}

I'm a little confused about your expression "...send the object to the other side..."

Regarding iBatis, approach A could be easily achived, because I could complement the update method with an extra parameter that would tell my DAO which update to use. For example, if we take the iBatis update example above, I would have the following generic method in my base DAO:

public void saveOrUpdate(String idOperation, Object object)
{
sqlMap.update(idOperation, object)
}

Can you see the benefits?

sorry missed a comma.

No, people send....