hello - i was looking through the documentation and i see that i can do queries (selects) in native sql. however i'd like to do an update in native sql (i want to do a mass update of objects that aren't currently in the session). can i do a native sql update in hibernate - or should i go directly through jdbc?
thanks for your time
chris

use session.connection()

In Hibernate 3.x there will be batch update available.

Max, what about objects status in the current session after commit() such mass updates to database ?!. I think this is an important issue to take care of.

this cannot be done efficiently.

you either use the normal update features and have db and inmemory insync or use batch updating as the first thing you do in a session before querying/loading stuff....

I have looked up forum for several opinions/investigations regarding this & found the following:
session.flush();
session.clear();
// Do your native sql batch updates /deletes here ..

Max, is this will make it effecient to be called anywhere in the session rather than at the start of session ?

calling .clear() is basically like resetting the session to be as it was in the beginning - but remember your objects are still not updated to reflect the changes you have done via your update/delete...

What do you think the status of already loaded objects after calling session.clear() ? what will be status in case of already loaded object tries to access one of its member fields/objects ?

sorry - i don't think I understand your question completly.....

are you asking what teh status of an already loaded object is after calling .clear ? Then it is detached - but that has nothing to do with your original question about performing bulk updates in sql.

Regarding what will be the "status" if an object loads its member fields/objects ? well - this is normal java so any fields it already has it can of course access. But if it fields/members/collections are not initialized at .clear time then accessing them will result in an exception since it cannot get to them (hence the "detached" status)

Fine, this means the following:
1- Some hibernate Object ready & initialized in memory, lets Call it Object001.
1- session.flush(); // makes sure all pending scripts commited to DB
2- session.clear(); // detach all hibernate Objects because next step may make it invalid
3- Object001 is null with all its details nulled
4- Do native sql updates.
5- Hibernate session should reload Object001 to reflect point 4.

Am I right ?

yes for all points except i don't what #3 does....Object001 contains whatever was loaded from the db.

#5 i would rephrase to:
5 - The user should reget/load Object001 via the session to reflect possible changes done via point 4.

OK, let me rephrase it:
1- Some Object loaded by hibernate ready & initialized in memory, lets Call it Object001.
2- session.flush(); // makes sure all pending scripts commited to DB
3- session.clear(); // detach all hibernate Objects from cache because native sql updates may make it invalid.
4- Object001 still has its values in point 1
5- Do native sql updates.
6- Object001 still has its values in point 1 which is now old & need to be refreshed.
7- User should reget/load Object001 via the session to reflect possible changes done via point 5.

yes looks more like it.

note: #3 has no effect on #4-#7, it is just there to let you have a clean slate.