I seem to remember Gavin mentioning that he may/has implemented something similiar, but if I remember correctly it was every column. It was meant more as a type of locking strategy.

I believe you could possibly do this using a custom EntityPersister subclass. Specifically, look at overriding the EntityPersister.update() method.

Yeah, its in CVS.

Great!
This way we won't face last Update vanishing problem.

Ashok

I'd suggest being very careful using this, or at least being aware of some potential issues. Especially if you either 1) use Oracle, or 2) use DB triggers and attempt to persist an entity a second time within the same session.

With triggers, say you create a new entity using Session.save(). The DB trigger then dynamically replaces some column value, but the entity object cached in Session does not know about this. Later on the same session you try to update that same entity instance. This extended where clause will now fail to find the record due to the mismatch.

With ORacle, the issue is much more insidious. Oracle has this wonderful "feature" where all empty values (i.e., zero-length strings) for varchar columns are replaced with null during insert/update statements. Unfortunately, it does not do the same thing on select statements. So the following:

will fail to find the just inserted record.

Just FYI...

Hi steve,
Yes we are using oracle ,thanks for pointing out that issue.
I have one more question.
If hibernate is going go include all the columns in where clause then i am seeing a probelm here.
for e.g
Two user are trying to modify the same record belongs to one employee.One user trying to modify salary and other user trying to modify the department.if they try to update the record at the same time then only one update will sucess and other will fail.

Update table set salary = new sal where id = originalid and salary = oldsalary and department = olddepartment.

Second user:
Update table set department = new department where id = originalid and salary = oldsalary and department = olddepartment.

Hope the example is clear.

Thats why I mentioned it was intended for locking previously.

You really are talking about two different things.


This is the purpose of locking or versioning your data. Simple locks based on only the changed columns are to simplistic most of the time. For example, say you have a table which holds a column "check_number", 'po_number', and 'payment_method'. User 1 modifies an existing record to update the 'check_number' field as the check has been received from the customer. User 2 modifies the same record to update the 'payment_method' to 'PO' and set the 'po_number', all by mistake. Simple column-based locking will not detect this situation. And even though you have lost no data because it is all seperate columns, the lock did not work. Use a version column or a timestamp column to acheive this much more effectively.

I am suprised the altenative solution was not proposed.

If you need to use dynamic updates, but are updating in a different session than the load, you could use your own dirty determination (perhaps dirty flags in the object) and write an Interceptor that implements findDirty(). Then your findDirty() would simply need to check your dirty flags and return the dirty properties.

(warning - I have not actually run a code test against this.. yet)

Probably because findDirty() in-and-of itself will not constrain the update statement to only changed values. You still need to enable dynamic-update for that to occur.

Ah, but the original poster was originally asking about this in conjunction with dynamic-update enabled, so I was assuming dynamic-update enabled.

So the combination of a findDirty interceptor combined with dynamic-update=true should give the effect needed, even if the object is loaded in one session and saved in another.

If Hibernate itself is aware of this behaviour (in Oracle), it should be able to work around it. I have used the MVCSoft persistence manager (EJB CMP 2.0 implementation) in the past, and it does do this form of update, and properly handles this issue.

I insist that Oracle should fix this bug, not Hibernate ;)

It is trivial to write a Hibernate usertype to work around this problem.