На самом деле обновление отдельного поля при обновление сущности сложный момент с точки зрения бизнес логики. Тем более с позиции стороннего наблюдателя все выглядит довольно правдободобно. Да и реализовать намного проще, через prepared statement query чем заниматся динамическим составнением апдейта.
orphanRemoval=true hibernate issue-> hibernate.atlassian.net/browse/HHH-9330?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&showAll=true @Test @Commit public void mergeCollections() { Client client = getSession().get(Client.class, 10); //client.setAccounts(new ArrayList()); client.getAccounts().clear(); } У меня этот тест печатает только 2 select запросы. Чтобы увидеть delete запросы. Нужно было в Client указать любой CascadeType.
Добрый день, спасибо за отличный доклад, запустил тест из класса LazyLoadingTest - loadMethod() Порядок вызова не соответствует тому что у вас в докладе. Сначала произошел запрос в БД, затем вывод "
Здравствуйте, спасибо. Скорее всего вы сделали clean install, а потом запустили тест. Удалите target папочку и запустите тест заново. Проблема в том что когда вы делаете clean install выполняется hibernate-enhance-maven-plugin плагин, можете посмотреть в pom файле и Hibernate делает магию, модифицируя сущность. На данном этапе плагин не очень хорошо работает - частенько дает сбой и ломает лейзи, не только для load метода, а так же в сущностях. Мой совет - не использовать, пока, этот плагин.
Плагин в pom файле у меня закомментирован, папку target удалял, результат один - load() возвращает прокси, но запрос к БД происходит в момент вызова метода load
Тогда еще вариант - вы в дебаге запускаете??? Если вы запускаете в дебаге и делает ALT+F8 Evaluate expression(Windows) на обьекте чтоб посмотреть прокси он или нет, или если вы знаете с версии Intellij IDEA 15 справа показывается значение обьекта - то у вас вызывается метод toString у обьекта. Вот screen shot - www.dropbox.com/s/rgftzcswsc98yx8/hibernate_proxy_debug.png?dl=0
Примеры того, как то, что видишь в коде не соответствует поведению приложения. И хорошо, если сам написал - и сам заметил проблему. А если это написал кто-то другой год назад и уволился? Не редко прекрасная идея ускорить разработку выливается в кучу ненужных часов на поиски магии.
так часто бывает - берешь фреймворк, чтоб ускорить разработку, но в итоге сэкономленное время потом тратишь на фикс багов и исследование магии, и в итоге тоже самое получается по времени :)
@@владимирсенцов-р1ю не согласен, с ними много проблем, очень часто встречал проекты где люди избавлялись от них из-за сложности поддержки и тестирования
Че-то вообще уже не понимаю нафига тогда этот хибернейт нужен - что-то гемора просто вагон и маленькая тележка. Нативные запросы проще и понимания процесса на порядок больше.
Ох ребята , спасибо за старание , но так basics не рассказывают Представьте , я вот учусь , хочу посмотреть на хибернейт от вас , поделать примеры ...а тут увы , ни основ , ни что да как
Посижу пока на CRUD операциях, слишком много граблей закопано.
На самом деле обновление отдельного поля при обновление сущности сложный момент с точки зрения бизнес логики. Тем более с позиции стороннего наблюдателя все выглядит довольно правдободобно. Да и реализовать намного проще, через prepared statement query чем заниматся динамическим составнением апдейта.
Скачал тесты, не работают(
Есть вопрос, а разве перед нативными запросами в hibernate, не делается flush с версии 4.3.0? (Если я не ошибаюсь, конечно :) )
если вы используется EntityManager - то да, если Session - нет
orphanRemoval=true hibernate issue->
hibernate.atlassian.net/browse/HHH-9330?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&showAll=true
@Test
@Commit
public void mergeCollections() {
Client client = getSession().get(Client.class, 10);
//client.setAccounts(new ArrayList());
client.getAccounts().clear();
}
У меня этот тест печатает только 2 select запросы. Чтобы увидеть delete запросы. Нужно было в Client указать любой CascadeType.
Добрый день, спасибо за отличный доклад, запустил тест из класса LazyLoadingTest - loadMethod() Порядок вызова не соответствует тому что у вас в докладе. Сначала произошел запрос в БД, затем вывод "
Здравствуйте, спасибо. Скорее всего вы сделали clean install, а потом запустили тест. Удалите target папочку и запустите тест заново. Проблема в том что когда вы делаете clean install выполняется hibernate-enhance-maven-plugin плагин, можете посмотреть в pom файле и Hibernate делает магию, модифицируя сущность. На данном этапе плагин не очень хорошо работает - частенько дает сбой и ломает лейзи, не только для load метода, а так же в сущностях. Мой совет - не использовать, пока, этот плагин.
Плагин в pom файле у меня закомментирован, папку target удалял, результат один - load() возвращает прокси, но запрос к БД происходит в момент вызова метода load
Тогда еще вариант - вы в дебаге запускаете??? Если вы запускаете в дебаге и делает ALT+F8 Evaluate expression(Windows) на обьекте чтоб посмотреть прокси он или нет, или если вы знаете с версии Intellij IDEA 15 справа показывается значение обьекта - то у вас вызывается метод toString у обьекта. Вот screen shot - www.dropbox.com/s/rgftzcswsc98yx8/hibernate_proxy_debug.png?dl=0
Все верно, спасибо, в дебаге вызывается toString.
пожалуйста :)
Игорь, а почему вы в IDE отключили показ строчек кода?
Или вы так привыкли работать?
проще по номеру строчки место быстрее искать
Я не особо придаю значение номеру строчки, но если нужно использую хот кей
Таймкодов явно... не хватает.
Доклад понравился, спасибо. Жаль только что код снимают на камеру. Но это уже вопрос к организаторам.
Примеры того, как то, что видишь в коде не соответствует поведению приложения. И хорошо, если сам написал - и сам заметил проблему. А если это написал кто-то другой год назад и уволился?
Не редко прекрасная идея ускорить разработку выливается в кучу ненужных часов на поиски магии.
так часто бывает - берешь фреймворк, чтоб ускорить разработку, но в итоге сэкономленное время потом тратишь на фикс багов и исследование магии, и в итоге тоже самое получается по времени :)
@@igordmitriev6543 Поэтому процедуры это хорошо.
@@владимирсенцов-р1ю не согласен, с ними много проблем, очень часто встречал проекты где люди избавлялись от них из-за сложности поддержки и тестирования
@@igordmitriev6543 Ну тестировать их не сложно. Если держать на девелоперской машине копию базы. А вот с версионированностью проблемы есть конечно.
Че-то вообще уже не понимаю нафига тогда этот хибернейт нужен - что-то гемора просто вагон и маленькая тележка. Нативные запросы проще и понимания процесса на порядок больше.
Ох ребята , спасибо за старание , но так basics не рассказывают
Представьте , я вот учусь , хочу посмотреть на хибернейт от вас , поделать примеры ...а тут увы , ни основ , ни что да как
басикс найдешь в книгах)
@@Gibsonen правда ?