技术原因是不在Config.groovy中将grails.gorm.autoFlush和grails.gorm.failOnError设置为true？

Question

除了这样做的明显性能影响之外,有什么技术理由不设置grails.gorm.autoFlush = true和grails.gorm.failOnError = true进入Config.groovy？

Answer 1

GORM是Hibernate的包装器(至少是其中一个实现 - 现在还有各种NoSQL实现,比如Redis).通过设置autoFlush到true你拒绝休眠的机会来优化它使数据库的调用.例如,当单个插入可能已足够时,您可能会导致它稍后插入更新.这没有任何本质上的坏处,它只是没有必要而且效率较低.Hibernate非常聪明,可以知道什么时候需要写入数据库并且可以优化 - 你已经抽象出了这个问题.

failOnError每当您尝试保存未验证的域对象时,设置将导致save抛出异常.在构建涉及从用户输入创建对象的应用程序时,对象不能验证是很正常的 - 缺少输入,格式错误等.应该为异常和错误保存异常处理 - 它不应该用于应用程序的正常流程.save()在成功保存对象时返回对象,否则返回null,这使您可以更方便地将验证作为应用程序流的一部分进行处理,而不是将try-catch块放在一起.

Peter Ledbrook(Grails in Action的作者)撰写了一系列很多"GORM Gotchas"文章,其中更详细地讨论了其中的一些问题 - 非常值得一读:第1 部分,第2 部分和第3部分.

Answer 2

我曾经两次使用并且相信我有很多理由想和你分享.

为何使用grails.gorm.autoFlush = true？

当我调用save()时没有真正保存实体/域是因为我没有告诉API要做什么.当Hibernate在执行之前在16行上刷新并且给调试带来痛苦时,它会引起许多麻烦.你的团队不是Java开发人员,这是一个很大的痛苦.

Grails从Ruby借用了Active Record Pattern(直接调用了持久化方法,比如domain.save),但是当调用save()时,Ruby确实做了持久性,但是Grails没有,因为他们隐藏了来自API用户的'Hibernate Session' /开发者.我们可以使用此配置参数解决GORM 的严重泄漏抽象故障.

一旦设置好,如果你真的需要Hibernate的工作单元模式,它链接SQL调用并且出于性能原因只执行一次,只需domain.save(flush:false)在需要时使用.

为何使用grails.gorm.failOnError = true？

永远不要隐藏用户的异常.所有优秀的Java程序员都知道这一点.如果你"确实"需要隐藏,请将其记录为警告.但是,当Grails验证失败(没有日志!)并且使程序员失明时,这不幸发生,对于那些不知道这一点的新手来说真的很难.最有经验的人只是说'它很容易调整'但它只是一种恶毒而不是更好的方式.

为了这个缘故,这些GORM Leaky Abstraction是我过去对Grails唯一的抱怨.现在他们刚刚使用了这个配置参数.