Развлекуха с Hibernate
На днях был озадачен в логе никому не нужным update. Hibernate почему-то обновлял запись пользователя при каждом обращении к его объекту.
Пытаясь выявить причину изменения объекта, а соответственно причину установки для сессии isDirty() = true установил для объекта режим кэширования read-only.
В результате в логах возникла следующая ошибка:
Can't write to a readonly object
Выявить конкретное поле, которое было изменено оказалось не возможно - hibernate апдейтил целиком всю строчку, а не только изменившиеся поля. Существуют методы отладки таких ошибок с помощью AuditInterceptors но они требуют времени на изучение.
Простейший метод отладки ошибок такого рода - тотальное комментирование полей в файлах .hbm.xml только так можно быстро выявить поле которое изменяется.
В результате была найдена противная ошибка - в геттере (getName) был вызов сеттера (setName) если это имя было null. Hibernate ловит что был вызван сеттер и метит объект как грязный и требующий сохранения.
Отсюда вывод:
НИКОГДА НЕ ВЫЗЫВАЙТЕ SETTER из МЕТОДОВ GET!
Пытаясь выявить причину изменения объекта, а соответственно причину установки для сессии isDirty() = true установил для объекта режим кэширования read-only.
В результате в логах возникла следующая ошибка:
Can't write to a readonly object
Выявить конкретное поле, которое было изменено оказалось не возможно - hibernate апдейтил целиком всю строчку, а не только изменившиеся поля. Существуют методы отладки таких ошибок с помощью AuditInterceptors но они требуют времени на изучение.
Простейший метод отладки ошибок такого рода - тотальное комментирование полей в файлах .hbm.xml только так можно быстро выявить поле которое изменяется.
В результате была найдена противная ошибка - в геттере (getName) был вызов сеттера (setName) если это имя было null. Hibernate ловит что был вызван сеттер и метит объект как грязный и требующий сохранения.
Отсюда вывод:
НИКОГДА НЕ ВЫЗЫВАЙТЕ SETTER из МЕТОДОВ GET!