Hello,

I'm new to hibernate (obviously from this question :-). I have a scenario where I have to update a column in a row in the database.

Presently what I have to do is load() the object, change the field, then saveOrUpdate() the POJO.

It strikes me as iefficient to read the object first. So I tried creating an instance of the POJO, assigning the ID field correctly, setting the value of the column-to-change, and calling session.update().

The transaction failed stating that I had non-nullable fields defied. Of course I can't have those fields NULL in the database, but I thought perhaps I could keep the null in the POJO, and have hibernate update that column without having to load() the object first.

Any thoughts?

Thanks,

Mal.

Also, I thought hibernate was supposed to only update() the columns that changed, not all of them?

I am loading() the record in Hibernate, then modifying one field (the password, then calling saveOrUpdate().

When looking at the hibernate SQL logging, I see something like...

Hibernate: select a, b, c, d, e, f, g
Hibernate: update users set b, c, d, e, f, g

... even though I'm only changing field E for example.

Any thoughts?

Mal.

dynamic-update=true

You do NOT need to call saveOrUpdate() here!



Don't do this.

Michael,

Setting dynamic-update did in fact solve the second problem... Only the necessary columns are being updated.

However, my first problem (having to load() and object before being able to update it) has not been solved.

Gavin seems to think (correctly) that my "keep POJO values null except those I want to update" method is not good. I promptly ended up with null fields in my database :-) Woops.

Is is possible for me to update the user's password without first having to load the entire user object into a POJO?

Perhaps this is one of the db versus java-persistence issues I have to get used to?

Thanks,

Greg.

Gavin,

I'm not quite sure how the object will get persisted if I don't call that method, or call update() instead... What do you propose I do instead? Simply modifying the POJO value won't get the object stored in the DB (as far as I know?).

Thanks,

Malachii.

Yes, thats exactly what happens.

Please read the documentation.