开发者

Hibernate: Dirty Checking and Only Update of Dirty Attributes?

开发者 https://www.devze.com 2022-12-27 17:38 出处:网络
In the \"good old JDBC days\" I wrote a lot of SQL code that did very targeted updates of only the \"attributes/members\" that were actually changed:

In the "good old JDBC days" I wrote a lot of SQL code that did very targeted updates of only the "attributes/members" that were actually changed:

For example, consider an object with the following members:

public String开发者_运维技巧 name;
public String address;
public Date date;

If only date was changed in some Business Method I would only issue an SQL UPDATE for the date member.

It seems however (that's my "impression" of Hibernate) that when working with a standard Hibernate mapping (mapping the full class), even updates of only a single member lead to a full update of the object in the SQL statements generated by Hibernate.

My questions are:

  1. Is this observation correct, that Hibernate does not intelligently check (in a fully mapped class), what member(s) where changed and then only issue updates for the specific changed members, but rather always will update (in the generated SQL Update Statement) all mapped members (of a class), even if they were not changed (in case the object is dirty due to one member being dirty...)

  2. What can I do to make Hibernate only update those members, that have been changed? I am searching for a solution to have Hibernate only update the member that actually changed.

(I know Hibernate does quite some work on dirty-checking, but as far as I know this dirty checking is only relevant to identify if the object as whole is dirty, not what single member is dirty.)


Actually, you can specify the options dynamic-update and dynamic-insert in a class mapping. It does just that. More info here.


Hibernate just update what you really want to

public class Person {

    private Integer id;

    public String name;
    public String address;
    public Date date;

    // getter's and setter's

}

And you do something like

Person person = (Person) sessionFactory.openSession().get(Person.class, personId);

person.setName("jean");

Hibernate is smart enough to know just name property has been changed. Although you can see your log as follows

UPDATE PERSON (NAME, ADDRESS, DATE) VALUES (?, ?, ?);

Because Hibernate cache each SQL (INSERT, UPDATE, SELECT) query for EACH entity, again, it just update what you really want to.


You can optimize dirty checking a lot by implementing interfaces like CustomEntityDirtinessStrategy or Interceptor. See working example at http://prismoskills.appspot.com/lessons/Hibernate/Chapter_20_-_Dirty_checking.jsp


I think dynamic-update is good if you have heavy database load and one or multiple indexes to recreate on a full update (where all columns are updated, also those with unchanged values).

Maybe some DBMS recognize if UPDATE sets an already existing value to not update an index including that column. But many seem to be too "stupid" to recognize this (or don't check that for performance reasons).

Client side load for creating SQL queries is not a problem for most DB client applications. Interpretation of SQL in DB should take less time than recreating a big index.

Please correct me if I'm wrong!

0

精彩评论

暂无评论...
验证码 换一张
取 消