Hibernate ORM 5.3.0.Final 发布,新增多项支持

达尔文
 达尔文
发布于 2018年05月17日
收藏 4

Hibernate ORM 5.3.0.Final 已发布。

支持 JPA 2.2

Hibernate ORM 5.3 实现了对 JPA 2.2 的支持。

CDI 托管的 AttributeConverters

从 JPA 2.1 开始,应用程序可以使用 CDI 托管的 bean 作为实体事件侦听器。 JPA 2.2 扩展了这种支持,允许 AttributeConverters 成为 CDI 托管的 bean。

支持重复注释

JPA 2.2 定义了对重复注释的支持(@ java.lang.annotation.Repeatable)。 这包括添加 @TableGenerators 和 @SequenceGenerators。 所有其他 JPA 注释已经具有“包含”注释。

更多内容请查看发布主页

下载地址:

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Hibernate ORM 5.3.0.Final 发布,新增多项支持
加载中

精彩评论

青苗
青苗

引用来自“暗中观察”的评论

其实没啥好喷的,springdata是用hibernate实现的,导致它重新焕发了生机,我mybatis何时能一统天下,哎
来一波推荐 http://mp.baomidou.com/
kidfruit
kidfruit

引用来自“kidfruit”的评论

jpa强类型确实方便,既可以ql查询,又可以用criteria进行条件组装

引用来自“暗中观察”的评论

在动态sql方法,jpa用起来很不方便
jpa提供entitymanager,用@PersistenceContext注入得到,然后entitymanager.createquery("querystring with entity")得到强类型的结果即可。非常方便。这里ql不是sql,而是针对entity的强类型ql,在idea里面加了jpa的facets后,这个ql是可以自动补全的,比sql要更方便而且因为补全所以不易写错。另外createquery也支持criteria传入,需动态拼装就用criteria。至于crudrepository注解的接口定义如果常用的可以这么定义,只会临时用一次的再定义接口确实臃肿,用我说的entitymanager配合可以方便解决。
ahyyxx222
ahyyxx222
面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。

最新评论(30

kidfruit
kidfruit

引用来自“kidfruit”的评论

jpa强类型确实方便,既可以ql查询,又可以用criteria进行条件组装

引用来自“暗中观察”的评论

在动态sql方法,jpa用起来很不方便

引用来自“kidfruit”的评论

jpa提供entitymanager,用@PersistenceContext注入得到,然后entitymanager.createquery("querystring with entity")得到强类型的结果即可。非常方便。这里ql不是sql,而是针对entity的强类型ql,在idea里面加了jpa的facets后,这个ql是可以自动补全的,比sql要更方便而且因为补全所以不易写错。另外createquery也支持criteria传入,需动态拼装就用criteria。至于crudrepository注解的接口定义如果常用的可以这么定义,只会临时用一次的再定义接口确实臃肿,用我说的entitymanager配合可以方便解决。

引用来自“暗中观察”的评论

但维护起来就没那么方便了
@暗中观察 强类型维护跟正常代码维护一样,没有不方便的啊
ahyyxx222
ahyyxx222

引用来自“ahyyxx222”的评论

面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。

引用来自“暗中观察”的评论

这个自主决定无法就是用Criteria或者原生sql,但这样在java代码里写sql,阅读性太差了,不能mybatis简洁,或者你有更好的办法?

引用来自“ahyyxx222”的评论

你这种说法就和用原始的mybatis没做其他封装一样。hibernate可以用criteria,hql,sql,当然还可以抽离到单独的类里去维护,也可以把条件拼接用设计模式改造一下,绝对不会比放到xml里差,你要往业务代码里混sql那可是你自己的问题。

引用来自“暗中观察”的评论

又多了一个类来跟对应的bean对应,复杂度提高了
多一层维护sql的类,少了一个xml,复杂度并没有本质变化
ahyyxx222
ahyyxx222

引用来自“爽歪歪ES”的评论

我喜欢spring data jpa

引用来自“暗中观察”的评论

你要是复杂查询用多了,还能说这样的话,我就服了

引用来自“ahyyxx222”的评论

hibernate可以封装到什么程度呢?反正多表关联,查询字段列筛选,与或条件组合,范围查询,条件查询这种常规的东西,我们都不需要写SQL,也不需要会用Criteria,因为我们实现了给查询条件对象的字段上加几个自定义注解,底层dao自动解析组装成Criteria。200多个表的系统里只有几条为了批量update写的SQL。至于再复杂的SQL,要么是设计有问题,应该拆出更多中间表,要么就写原生SQL呗,一个系统里这种复杂度的SQL能占百分之几?

引用来自“暗中观察”的评论

看系统,我原来的公司,复杂查询就占了60%,而且hibernate有n+1查询问题,你这种封装,阅读性我感觉不高,对程序员的要求高,基本的按条件查询与更新,hibernate也能搞得很复杂
相反,阅读性非常清晰,这里回复不好贴代码就不讨论这个了。这种做法不需要你写SQL也不需要你会Criteria,对程序员的高要求从哪来?他只要记住一个注解的某个type参数表示哪种查询条件而已。n+1问题我们同样解决了,可以通过一个boolean字段,再加一个自定义注解就能在运行时控制他是一条sql直接查出所有关联数据,还是不要取,懒加载。
暗中观察
暗中观察

引用来自“kidfruit”的评论

jpa强类型确实方便,既可以ql查询,又可以用criteria进行条件组装

引用来自“暗中观察”的评论

在动态sql方法,jpa用起来很不方便

引用来自“kidfruit”的评论

jpa提供entitymanager,用@PersistenceContext注入得到,然后entitymanager.createquery("querystring with entity")得到强类型的结果即可。非常方便。这里ql不是sql,而是针对entity的强类型ql,在idea里面加了jpa的facets后,这个ql是可以自动补全的,比sql要更方便而且因为补全所以不易写错。另外createquery也支持criteria传入,需动态拼装就用criteria。至于crudrepository注解的接口定义如果常用的可以这么定义,只会临时用一次的再定义接口确实臃肿,用我说的entitymanager配合可以方便解决。
但维护起来就没那么方便了
暗中观察
暗中观察

引用来自“ahyyxx222”的评论

面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。

引用来自“暗中观察”的评论

这个自主决定无法就是用Criteria或者原生sql,但这样在java代码里写sql,阅读性太差了,不能mybatis简洁,或者你有更好的办法?

引用来自“ahyyxx222”的评论

你这种说法就和用原始的mybatis没做其他封装一样。hibernate可以用criteria,hql,sql,当然还可以抽离到单独的类里去维护,也可以把条件拼接用设计模式改造一下,绝对不会比放到xml里差,你要往业务代码里混sql那可是你自己的问题。
又多了一个类来跟对应的bean对应,复杂度提高了
暗中观察
暗中观察

引用来自“爽歪歪ES”的评论

我喜欢spring data jpa

引用来自“暗中观察”的评论

你要是复杂查询用多了,还能说这样的话,我就服了

引用来自“ahyyxx222”的评论

hibernate可以封装到什么程度呢?反正多表关联,查询字段列筛选,与或条件组合,范围查询,条件查询这种常规的东西,我们都不需要写SQL,也不需要会用Criteria,因为我们实现了给查询条件对象的字段上加几个自定义注解,底层dao自动解析组装成Criteria。200多个表的系统里只有几条为了批量update写的SQL。至于再复杂的SQL,要么是设计有问题,应该拆出更多中间表,要么就写原生SQL呗,一个系统里这种复杂度的SQL能占百分之几?
看系统,我原来的公司,复杂查询就占了60%,而且hibernate有n+1查询问题,你这种封装,阅读性我感觉不高,对程序员的要求高,基本的按条件查询与更新,hibernate也能搞得很复杂
ahyyxx222
ahyyxx222

引用来自“爽歪歪ES”的评论

我喜欢spring data jpa

引用来自“暗中观察”的评论

你要是复杂查询用多了,还能说这样的话,我就服了
hibernate可以封装到什么程度呢?反正多表关联,查询字段列筛选,与或条件组合,范围查询,条件查询这种常规的东西,我们都不需要写SQL,也不需要会用Criteria,因为我们实现了给查询条件对象的字段上加几个自定义注解,底层dao自动解析组装成Criteria。200多个表的系统里只有几条为了批量update写的SQL。至于再复杂的SQL,要么是设计有问题,应该拆出更多中间表,要么就写原生SQL呗,一个系统里这种复杂度的SQL能占百分之几?
ahyyxx222
ahyyxx222

引用来自“ahyyxx222”的评论

面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。

引用来自“暗中观察”的评论

这个自主决定无法就是用Criteria或者原生sql,但这样在java代码里写sql,阅读性太差了,不能mybatis简洁,或者你有更好的办法?
你这种说法就和用原始的mybatis没做其他封装一样。hibernate可以用criteria,hql,sql,当然还可以抽离到单独的类里去维护,也可以把条件拼接用设计模式改造一下,绝对不会比放到xml里差,你要往业务代码里混sql那可是你自己的问题。
kidfruit
kidfruit

引用来自“kidfruit”的评论

jpa强类型确实方便,既可以ql查询,又可以用criteria进行条件组装

引用来自“暗中观察”的评论

在动态sql方法,jpa用起来很不方便
jpa提供entitymanager,用@PersistenceContext注入得到,然后entitymanager.createquery("querystring with entity")得到强类型的结果即可。非常方便。这里ql不是sql,而是针对entity的强类型ql,在idea里面加了jpa的facets后,这个ql是可以自动补全的,比sql要更方便而且因为补全所以不易写错。另外createquery也支持criteria传入,需动态拼装就用criteria。至于crudrepository注解的接口定义如果常用的可以这么定义,只会临时用一次的再定义接口确实臃肿,用我说的entitymanager配合可以方便解决。
爽歪歪ES

引用来自“爽歪歪ES”的评论

我喜欢spring data jpa

引用来自“暗中观察”的评论

你要是复杂查询用多了,还能说这样的话,我就服了
啥也不说了,亮剑吧
返回顶部
顶部