Технические причины не устанавливать для grails.gorm.autoFlush и grails.gorm.failOnError значение true в Config.groovy?

Question

Помимо очевидных последствий для производительности с этой точки зрения, есть веские технические причины , а не для установки grails.gorm.autoFlush = true и grails.gorm.failOnError = true в Config.groovy?

Answer 1

GORM - это оболочка для Hibernate (по крайней мере, это одна из реализаций - теперь есть также различные реализации NoSQL, такие как Redis).Установив для autoFlush значение true, вы лишаете Hibernate возможности оптимизировать обращения к базе данных.Например, вы можете заставить его вставлять, а потом обновлять, когда одной вставки было бы достаточно.В этом нет ничего плохого, просто в этом нет необходимости и он менее эффективен.Hibernate достаточно умен, чтобы знать, когда ему нужно выполнить запись в базу данных, и может оптимизировать - вы абстрагировали эту проблему.

Установка failOnError приведет к тому, что save выдает исключение всякий раз, когда вы пытаетесь сохранить доменобъект, который не проверяет.При создании приложения, которое включает в себя создание объектов из пользовательского ввода, вполне нормально, что объекты не проверяются - отсутствуют входные данные, неправильные форматы и т. Д. Обработка исключений должна быть сохранена для исключений и ошибок - она ​​не должна использоваться для нормального потока приложения,save() возвращает объект, когда объект был успешно сохранен, или возвращает ноль в противном случае, что дает вам более удобный способ обрабатывать проверку как часть потока приложения, а не помещать блоки try-catch повсеместно.

Питер Ледбрук (один из авторов Grails в действии) написал большую серию статей «GORM Gotchas», в которых он обсуждает некоторые из этих вопросов более подробно - стоит прочитать: part 1 , часть 2 & часть 3 .

Answer 2

Я использую оба и считаю, что у меня есть веские причины, которыми я хочу поделиться с вами.

Зачем использовать grails.gorm.autoFlush = true?

Причинана самом деле не сохранение сущности / домена при вызове save () - это не то, что я говорю API.Это вызывает много головной боли, когда Hibernate сбрасывает на 16 строк перед выполнением, и это приносит боль для отладки.Если ваша команда не является Java-разработчиком, это очень тяжело.

Grails позаимствовал шаблон активной записи из Ruby (методы персистентности которого вызываются напрямую, например, domain.save), но этот Ruby действительно работает, когдаВызывается save (), но Grails этого не делает, потому что они скрывают «Hibernate Session» от пользователя / разработчика API.Это серьезный Leak Abstraction сбой GORM, который мы можем решить с помощью этого параметра конфигурации.

После установки, если вам действительно нужен шаблон единицы работы Hibernate,который связывает вызовы SQL и делает это только один раз по соображениям производительности, просто используйте domain.save(flush:false), когда это необходимо.

Зачем использовать grails.gorm.failOnError = true?

Никогда не скрывайте исключение от пользователя.Все великие программисты на Java знают это.Если вам «действительно очень» нужно спрятаться, запишите это как предупреждение.Но, к сожалению, этого не происходит, когда валидация Grails завершается неудачей (без регистрации!) И делает программистов слепыми, что действительно трудно для новичков, которые этого не знают.Самые опытные парни просто говорят «это легко подправить», но это просто порок, а не лучший способ.

Ради этих утечек в GORM, это были единственные жалобы, которые у меня были с Grails в прошлом,В настоящее время они только что использовали этот конфиг params.

Answer 3

Хорошая серия статей Питера Ледбрука о GORM:

• http://spring.io/blog/2010/06/23/gorm-gotchas-part-1/
• http://spring.io/blog/2010/07/02/gorm-gotchas-part-2/
• http://spring.io/blog/2010/07/28/gorm-gotchas-part-3/

Хотя я не согласен с ним по поводу того, что делает сессия Hibernate.Он говорит, что «Flush: true заставляет Hibernate сохранять все изменения в базе данных сразу».Что ж, это может произойти только в нетранзакционном контексте, потому что когда вы находитесь в транзакции, операторы #SQL, которые сбрасываются из сеанса Hibernate, будут выполняться в сегменте отката вашей транзакционной СУБД.Таким образом, они не будут сохранены до тех пор, пока транзакция не будет совершена.

Когда в рамках транзакции вы выполняете другие операции, не связанные с БД, например, отправляете электронное письмо с подтверждением, вы хотите знать, возникало ли ранее какое-либо ограничение или ошибка времени выполнения БД, явно не объявленная в вашей проверке, дляНапример, вы отправили это подтверждение по электронной почте.

Мой совет: стратегия autoFlush (grails.gorm.autoFlush = true) сама по себе не ошибочна.Вы должны принять техническое решение о том, хотите ли вы использовать его или нет в начале, чтобы разработчики могли написать свой код соответствующим образом, поскольку они будут знать, нужно ли выполнять очистку явно или Hibernate сделает это для них в концеВы метод транзакции.

Другой распространенный пример использования, который следует рассмотреть, - это если вы хотите выполнить пакетную операцию с использованием GORM.Если вы не очищаете сеанс Hibernate от любого количества операций SQL, у вас возникнут проблемы.