Hibernate ORM 5.3.0.Final 发布,新增多项支持 - 开源中国社区
Hibernate ORM 5.3.0.Final 发布,新增多项支持
达尔文 2018年05月17日

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 发布,新增多项支持
分享
评论(30)
精彩评论
2

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

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

引用来自“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配合可以方便解决。
1
面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。
最新评论
0

引用来自“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配合可以方便解决。

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

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

引用来自“ahyyxx222”的评论

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

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

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

引用来自“ahyyxx222”的评论

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

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

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

引用来自“爽歪歪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直接查出所有关联数据,还是不要取,懒加载。
0

引用来自“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配合可以方便解决。
但维护起来就没那么方便了
0

引用来自“ahyyxx222”的评论

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

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

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

引用来自“ahyyxx222”的评论

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

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

我喜欢spring data jpa

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

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

引用来自“ahyyxx222”的评论

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

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

我喜欢spring data jpa

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

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

引用来自“ahyyxx222”的评论

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

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

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

引用来自“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配合可以方便解决。
0

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

我喜欢spring data jpa

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

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

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

我喜欢spring data jpa
你要是复杂查询用多了,还能说这样的话,我就服了
0

引用来自“kidfruit”的评论

jpa强类型确实方便,既可以ql查询,又可以用criteria进行条件组装
在动态sql方法,jpa用起来很不方便
0

引用来自“ahyyxx222”的评论

面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。
这个自主决定无法就是用Criteria或者原生sql,但这样在java代码里写sql,阅读性太差了,不能mybatis简洁,或者你有更好的办法?
0

引用来自“ahyyxx222”的评论

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

引用来自“li90hou”的评论

既然它俩同时存在,就肯定有存在的必要,只是应用场景不同罢了,不存在谁一定好,谁一定坏。
肯定是都有存在的必要的,也没有谁更好谁更坏。我只是说ORM的用法其实很丰富,比一般人印象中的可选用法要多。而且我认为应用场景不是不同,相反场景是一样的,都是为了更简单地操作关系数据库。只是面对同一场景不同的人选择了不同的办法应对。
0

引用来自“ahyyxx222”的评论

面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。
既然它俩同时存在,就肯定有存在的必要,只是应用场景不同罢了,不存在谁一定好,谁一定坏。
0

引用来自“kidfruit”的评论

jpa强类型确实方便,既可以ql查询,又可以用criteria进行条件组装
还可以对接queryDSL和jooq,爽翻天.
0
jpa强类型确实方便,既可以ql查询,又可以用criteria进行条件组装
0

引用来自“开源中国首席效率专家”的评论

mybatis中实体的一个字段是String类型的"123",但是数据库表是integer类型的,为什么还能插入?是什么在自动识别吗?
如果是mysql会自动转换
1
面向对象数据库成不了大器,那让关系数据库用起来尽可能像面向对象数据库,也只有ORM能做到,mybatis再怎么封装,终究是半自动化的,除了写代码还要维护脚本。而ORM你想全自动还是半自动甚至全手动,你都能自主决定。
0
我喜欢spring data jpa
顶部