Now I want to update a single column of a DB table by primary key.

If JDBC, only the following sql statment will be ok:
Update tableName
Set columnName = newvalue
Where idName = id

But with hibernate , I have to do the following:

PO po = (PO) session.load(PO.class, id);
po.setSomeAttribute(newValue);
sess.update(po);

Running these statments, Hibernate performs the following two DB operations (even with mapping file of PO set to lazy="true")
first Select from DB
secondly , update to DB.

Compare to JDBC, the first query is unnessary.

Does Hibernate provide any mechanism so that the first unnessary query can be avoided?

It must be possible to optimize this case if "lazy="true", the same is about delete by primary key. You can request feature/bug fix using bug tracker.

I have same issue with delete & can't find documentation. If I know the primary key why do I need to do a select to implement the delete?

because persistent objects has a lifecycle and need to check for cascade etc.

in H3 (and EJB3) you will get bulk delete/update (which will do stuff efficently on the db, but of course cannot be able to keep the session in a consistent state)

What does that mean. In hibernate 2.1.6 it is not possible to do this?

eh ? yes - that was what i wrote ,)

H2 does not have bulk delete, H3 will have it + I explained why we load objects before deleting them....

Can you give us an example of what you would need to check for? Why can't hibernate just delete blindly all sub collections if the mapping is set to cascade. What is the technical reason why this is not possible.

read hibernate in action (and think about it again when taking into consideration LifeCycle, Interceptor, session scoped identity and where attributes and other stuff you can map in the mapping files!)

We simply cannot deduce the equal sql deletes and magic java code you might want executed on an objects deletion....

but as i said - you will get the possiblity in H3 and EJB3 (where you get to execute update/delete with HQL/EJBQL but with that natural limitation that deletions will not be reflected into your current session!)

Max has got a key point right there. If Hibernate hasn't loaded an object into the session, there's no way for it to do all the lifecycle stuff. Not to mention the fact that your application code might not expect this state. It's a little like the mistake developers often make when using an ORM like Hibernate and then trying to change the database without telling the ORM about it.

hi max..

road map in hibernate.org:

Bulk update and delete

Hibernate 3.1 will introduce support for EJB3-style bulk UPDATE and bulk DELETE queries.

now bulk UPDATE/delete in H3 ? oyeah...glad to get it

the road map is the correct and precise one - I use H3 as a term for all what will and can come in H3.

so bulk delete/update is targeted for Hibernate 3.1

It must be possible to implement this optimization without breaking life cycle stuff, it can depend on mapping. If there is no application level triggers then you do not need to load object to update or delete. Boolean parameter in "load" can be used as hint too.

Submit a patch.

ok

I'm not saying that everyone will like it and the patch will be applied :) I'm saying that "must be possible" might be true.