- 浏览: 213176 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
strong8808:
activemq5.8.0 客户端,服务端启动序列图 -
xurichusheng:
第一题,如果使用 not exists 的话,可以改成:SEL ...
SQL笔试题 -
dingjun1:
cuisuqiang 写道如何解决呢?我的是对了也照样缓存增加 ...
事务未正确关闭引起的HIBERNATE SESSION不能正确关闭 -
dingjun1:
aijezdm915 写道lz ,我也是在写项目描述是犯愁,能 ...
如果在简历中描述项目 -
aijezdm915:
lz ,我也是在写项目描述是犯愁,能否给个你的简历demo,我 ...
如果在简历中描述项目
转载:http://www.blogjava.net/pear/archive/2006/11/05/79251.html
重新学习 Hibernate fetch lazy cascade inverse 关键字
Hibernate最让人头大的就是对集合的加载形式。
书看了N次了,还是没有真正理解Hibernate。所以下午专门做了下测试,对配置文件的意思加深了认识。
假设有两个表,Photos(一) --- picture(多)Photo包含picture集合
结论1: HQL代码 > fetch(配置) > lazy (配置)
结论2: 默认 lazy="true"
结论3: fetch 和 lazy 主要是用来级联查询的, 而 cascade 和 inverse 主要是用来级联插入和修改的
结论4: 如果你是用spring来帮你管理你的session, 并且是自动提交,延迟加载就等于没加载~_~(当然
除非你手动重新打开session然后手动Hibernate.initialize(set);然后关闭session.
结论5: cascade主要是简化了在代码中的级联更新和删除。
j结论6:老爸可以有多个孩子,一个孩子不能有多个老爸,而且老爸说的算, 孩子围着老爸转。
所以Photos老爸要有权力所以 cascade 这个关键子都是送给老爸的, 也就是级联更新,
老爸改姓了,儿子也得跟着改,呵呵。“不然,就没有零花钱咯”。
而Picture儿子整体挨骂,但是还是要维护父子之间良好的关系,对老爸百依百顺,所
以老爸就说,儿子,“关系,由你来维护(inverse="true") ,不然就不给零花钱。呵。”。
<set name="pictures" inverse="true" cascade="all">
<key>
<column name="photosid" not-null="true" />
</key>
<one-to-many class="girl.domain.Picture" />
</set>
测试代码:
Photos p = ps.getById(1);
Set<Picture> set = p.getPictures();
for(Picture pic : set){
System.out.println(pic.getId());
}
配置文件的一部分:
<set name="pictures" inverse="true" cascade="all" >
<key>
<column name="photosid" not-null="true" />
</key>
<one-to-many class="girl.domain.Picture" />
</set>
测试过程会对配置文件不断修改:并且从来不曾手动重新打开session
测试结构:
当配置条件为 lazy=true 一句查询 测试代码中没有调用getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
lazy=true 一句查询 有getPicture()
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
lazy=true 一句查询 有getPicture() 并且访问了里面的元数Picture 且有异常抛出
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
lazy="false" 两句查询 肯定没问题,因为全部数据都个查了出来 所以怎么调用都正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
Hibernate: select pictures0_.photosid as photosid1_, pictures0_.id as id1_, pictures0_.id as id2_0_, pictures0_.photosid as photosid2_0_, pictures0_.name as name2_0_, pictures0_.clicked as clicked2_0_, pictures0_.uploaddate as uploaddate2_0_, pictures0_.size as size2_0_, pictures0_.description as descript7_2_0_, pictures0_.uri as uri2_0_ from super.picture pictures0_ where pictures0_.photosid=?
fetch="join" 一句查询 效果 == lazy="false" 呵呵,哪个效率高,我就不知道了。。。。。。。。。。。
Hibernate: select photos0_.id as id0_1_, photos0_.userid as userid0_1_, photos0_.typeid as typeid0_1_, photos0_.name as name0_1_, photos0_.createtime as createtime0_1_, photos0_.description as descript6_0_1_, photos0_.faceid as faceid0_1_, photos0_.uri as uri0_1_, pictures1_.photosid as photosid3_, pictures1_.id as id3_, pictures1_.id as id2_0_, pictures1_.photosid as photosid2_0_, pictures1_.name as name2_0_, pictures1_.clicked as clicked2_0_, pictures1_.uploaddate as uploaddate2_0_, pictures1_.size as size2_0_, pictures1_.description as descript7_2_0_, pictures1_.uri as uri2_0_ from super.photos photos0_ left outer join super.picture pictures1_ on photos0_.id=pictures1_.photosid where photos0_.id=?
不加fetch="join" 一句查询 没有getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
不加fetch="join" 一句查询 有getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
不加fetch="join" 一句查询 有getPicture() 并且访问里面的元素Picture的ID 有异常抛出
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
来个两兵交战 fetch="join" lazy="true" 呵呵 结果,一句查询, 结构正常 所以就当lazy不存在好了。 看来fetch 是老大。、、、、、、、、、、、、、
Hibernate: select photos0_.id as id0_1_, photos0_.userid as userid0_1_, photos0_.typeid as typeid0_1_, photos0_.name as name0_1_, photos0_.createtime as createtime0_1_, photos0_.description as descript6_0_1_, photos0_.faceid as faceid0_1_, photos0_.uri as uri0_1_, pictures1_.photosid as photosid3_, pictures1_.id as id3_, pictures1_.id as id2_0_, pictures1_.photosid as photosid2_0_, pictures1_.name as name2_0_, pictures1_.clicked as clicked2_0_, pictures1_.uploaddate as uploaddate2_0_, pictures1_.size as size2_0_, pictures1_.description as descript7_2_0_, pictures1_.uri as uri2_0_ from super.photos photos0_ left outer join super.picture pictures1_ on photos0_.id=pictures1_.photosid where photos0_.id=?
重新学习 Hibernate fetch lazy cascade inverse 关键字
Hibernate最让人头大的就是对集合的加载形式。
书看了N次了,还是没有真正理解Hibernate。所以下午专门做了下测试,对配置文件的意思加深了认识。
假设有两个表,Photos(一) --- picture(多)Photo包含picture集合
结论1: HQL代码 > fetch(配置) > lazy (配置)
结论2: 默认 lazy="true"
结论3: fetch 和 lazy 主要是用来级联查询的, 而 cascade 和 inverse 主要是用来级联插入和修改的
结论4: 如果你是用spring来帮你管理你的session, 并且是自动提交,延迟加载就等于没加载~_~(当然
除非你手动重新打开session然后手动Hibernate.initialize(set);然后关闭session.
结论5: cascade主要是简化了在代码中的级联更新和删除。
j结论6:老爸可以有多个孩子,一个孩子不能有多个老爸,而且老爸说的算, 孩子围着老爸转。
所以Photos老爸要有权力所以 cascade 这个关键子都是送给老爸的, 也就是级联更新,
老爸改姓了,儿子也得跟着改,呵呵。“不然,就没有零花钱咯”。
而Picture儿子整体挨骂,但是还是要维护父子之间良好的关系,对老爸百依百顺,所
以老爸就说,儿子,“关系,由你来维护(inverse="true") ,不然就不给零花钱。呵。”。
<set name="pictures" inverse="true" cascade="all">
<key>
<column name="photosid" not-null="true" />
</key>
<one-to-many class="girl.domain.Picture" />
</set>
测试代码:
Photos p = ps.getById(1);
Set<Picture> set = p.getPictures();
for(Picture pic : set){
System.out.println(pic.getId());
}
配置文件的一部分:
<set name="pictures" inverse="true" cascade="all" >
<key>
<column name="photosid" not-null="true" />
</key>
<one-to-many class="girl.domain.Picture" />
</set>
测试过程会对配置文件不断修改:并且从来不曾手动重新打开session
测试结构:
当配置条件为 lazy=true 一句查询 测试代码中没有调用getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
lazy=true 一句查询 有getPicture()
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
lazy=true 一句查询 有getPicture() 并且访问了里面的元数Picture 且有异常抛出
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
lazy="false" 两句查询 肯定没问题,因为全部数据都个查了出来 所以怎么调用都正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
Hibernate: select pictures0_.photosid as photosid1_, pictures0_.id as id1_, pictures0_.id as id2_0_, pictures0_.photosid as photosid2_0_, pictures0_.name as name2_0_, pictures0_.clicked as clicked2_0_, pictures0_.uploaddate as uploaddate2_0_, pictures0_.size as size2_0_, pictures0_.description as descript7_2_0_, pictures0_.uri as uri2_0_ from super.picture pictures0_ where pictures0_.photosid=?
fetch="join" 一句查询 效果 == lazy="false" 呵呵,哪个效率高,我就不知道了。。。。。。。。。。。
Hibernate: select photos0_.id as id0_1_, photos0_.userid as userid0_1_, photos0_.typeid as typeid0_1_, photos0_.name as name0_1_, photos0_.createtime as createtime0_1_, photos0_.description as descript6_0_1_, photos0_.faceid as faceid0_1_, photos0_.uri as uri0_1_, pictures1_.photosid as photosid3_, pictures1_.id as id3_, pictures1_.id as id2_0_, pictures1_.photosid as photosid2_0_, pictures1_.name as name2_0_, pictures1_.clicked as clicked2_0_, pictures1_.uploaddate as uploaddate2_0_, pictures1_.size as size2_0_, pictures1_.description as descript7_2_0_, pictures1_.uri as uri2_0_ from super.photos photos0_ left outer join super.picture pictures1_ on photos0_.id=pictures1_.photosid where photos0_.id=?
不加fetch="join" 一句查询 没有getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
不加fetch="join" 一句查询 有getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
不加fetch="join" 一句查询 有getPicture() 并且访问里面的元素Picture的ID 有异常抛出
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
来个两兵交战 fetch="join" lazy="true" 呵呵 结果,一句查询, 结构正常 所以就当lazy不存在好了。 看来fetch 是老大。、、、、、、、、、、、、、
Hibernate: select photos0_.id as id0_1_, photos0_.userid as userid0_1_, photos0_.typeid as typeid0_1_, photos0_.name as name0_1_, photos0_.createtime as createtime0_1_, photos0_.description as descript6_0_1_, photos0_.faceid as faceid0_1_, photos0_.uri as uri0_1_, pictures1_.photosid as photosid3_, pictures1_.id as id3_, pictures1_.id as id2_0_, pictures1_.photosid as photosid2_0_, pictures1_.name as name2_0_, pictures1_.clicked as clicked2_0_, pictures1_.uploaddate as uploaddate2_0_, pictures1_.size as size2_0_, pictures1_.description as descript7_2_0_, pictures1_.uri as uri2_0_ from super.photos photos0_ left outer join super.picture pictures1_ on photos0_.id=pictures1_.photosid where photos0_.id=?
发表评论
-
solr/home 设置
2013-04-21 00:44 1246solr/home是solr实例化core核的依据和入口,是必 ... -
CronTrigger Tutorial
2011-02-24 18:58 913转载地址:http://www.quartz-schedule ... -
事务未正确关闭引起的HIBERNATE SESSION不能正确关闭
2010-10-30 13:46 1666问题现象: 第一 ... -
hibernate 四种抓取策略
2010-10-24 10:42 923转载:http://www.cnblogs.com ... -
cas分析
2010-05-10 13:20 1973Central Authentication Service ... -
FCKeditor2.6.5及后续版本 for PHP配置及中文上传乱码解决!
2009-12-10 13:37 1407对于Fckeditor上传中文名文件时显示乱码的问题,现公布方 ... -
xpath语法
2009-10-12 21:02 928转载:http://www.w3schools.com/XPa ... -
jstl标签中循环map
2009-10-12 20:58 2587<% Map map = new HashMap(); ... -
log4j输出多个自定义日志文件(分离日志)
2009-06-24 11:30 2600转载: http://wangjc-opal.iteye.co ... -
错误: 必须限制口令文件读取访问
2008-10-10 17:06 3090转载:http://hi.baidu.com/lifecodi ... -
spring AOP使用结总结
2008-09-12 14:23 1107AOP使用结总结 最近需要 ... -
log4j手动加载配置文件
2008-09-10 15:26 3173PropertyConfigurator.configur ... -
spring集成hibernate使用缓存简单实例
2008-07-08 18:20 2359这部分为转载:http://www ... -
lucene应用入门1
2008-07-06 16:49 2150简单的建立索引和索引 ... -
多对多查询的条件设置和删除问题
2008-07-03 14:50 1500select 父 from 父类 父 left join 父. ... -
DOM4J学习笔记
2008-07-01 15:07 3714DOM4J简单介绍 基本使用 读取XML文档 Import o ... -
延迟初始化错误(转载)
2008-06-12 17:52 1009转载地址:http://lz726.ite ... -
UUID [转帖]
2008-05-20 15:25 921/***********本人原创,欢迎转载,转载请保留本人信息 ... -
一段简单的发送邮件代码
2008-04-28 15:57 1042package send; import java. ... -
HIBERNATE2 CLOB字段延迟加载办法[转载]
2008-04-18 13:49 3086[转载]http://callan.iteye.com/blo ...
相关推荐
根据提供的文件信息,我们可以深入探讨Hibernate框架中的几个关键概念,特别是`fetch`, `lazy`, `cascade`, 和 `inverse`关键字的使用与理解。这四个概念在处理对象关系映射(ORM)时非常重要,尤其是在Java环境下...
@OneToMany(mappedBy = "class", cascade = CascadeType.ALL, fetch = FetchType.LAZY) private List<Student> students; // getters & setters } @Entity public class Student { @Id private Long id; @...
<set name="students" inverse="true" cascade="all" fetch="subselect"> ``` #### 五、批量处理与性能优化 - **Batch Size**: Hibernate支持批量处理,可以通过设置`batch_size`属性来控制批量加载的数量...
Hibernate 是一个流行的对象关系映射(ORM)框架,它允许开发者使用 Java 对象来操作数据库,消除了直接编写 SQL 的需要。在 Hibernate 中,映射关系是将数据库表与 Java 类之间的关联方式,使得对象模型可以与关系...
在Hibernate中,可以通过@OneToOne注解来定义,可以是外键约束或主键共享,需要配置fetch属性来决定何时加载关联对象,比如LAZY或EAGER。 2. **一对多关联(OneToMany)**:一个实体可以与多个其他实体关联。这通常...
- **一对多**:在映射文件中,通过 `<set>` 标签定义一对多关系,并可通过 `inverse`、`cascade`、`lazy` 和 `fetch` 控制行为。 - **多对一**:通过 `<many-to-one>` 标签定义,可设置 `fetch` 和 `cascade` 属性。...
<set name="orders" table="orders" inverse="true" lazy="true" cascade="all"> ``` 而在`Order`的映射文件中: ```xml ``` **示例应用** 为了更好地理解,我们可以创建一个简单的示例。首先,创建`...
在多对多映射中,这两个标签用于定义关系的一端,它们包含属性如inverse(反向),cascade(级联操作),fetch(加载策略)等。 4. **中间表与关联表**: 在多对多关系中,通常需要一个中间表来存储两个实体的主键,...
### Hibernate学习笔记知识点详解 #### Hibernate简介 - **定义与作用**:Hibernate是一种“对象/关系映射”(Object/Relational Mapping, ORM)技术,主要用于解决Java对象模型与关系数据库模型之间的不匹配问题。 -...
4. **fetch策略**:通过`fetch`属性可以指定加载关联的方式,如`FetchType.LAZY`(懒加载)和`FetchType.EAGER`(立即加载)。默认情况下,一对多关系是懒加载的,以避免不必要的性能开销。 5. **级联操作**:通过`...
- **属性**: `lazy=false`表示被动方的记录由Hibernate负责加载,存储在主控方的集合中。 - **示例**: - `java.util.Set` 或 `net.sf.hibernate.collection.Bag` 类型的集合。 #### 九、双向关联管理 - **inverse...
@OneToMany(mappedBy = "user", fetch = FetchType.LAZY) private Set<Order> orders; ``` 这样,只有在真正访问`orders`集合时,Hibernate才会去数据库查询订单。 ### 5. 级联操作 通过设置`CascadeType`,可以...
3. `fetch`属性:用于指定关联数据的加载策略,如`EAGER`(立即加载)或`LAZY`(延迟加载)。 4. 外键约束:在数据库中,可以设置外键约束以确保数据一致性,但不是必须的,Hibernate可以通过程序逻辑实现数据一致性...
- **懒加载与瞬时加载**:可以通过`lazy="true"`(默认)或`fetch="LAZY"`(注解中为`@OneToMany(fetch = FetchType.LAZY)`)实现懒加载,以提高性能,避免一次性加载大量数据。 - **级联操作**:通过`cascade`属性...
### Hibernate学习笔记:对象/关系数据库映射(二)——集合映射 #### 1. 集合映射概述 在对象/关系映射(ORM)领域中,Hibernate 是一个非常强大的工具,它能够帮助开发者高效地进行 Java 对象与数据库记录之间的...
在Java的持久化框架Hibernate中,一对多(Many-to-One)和多对一(One-to-Many)的关系映射是数据库关系模型中的常见关联类型。本文将深入探讨这两种关联方式在使用Hibernate时的配置,包括基于注解(Annotation)和...
通过`@OneToMany`注解来配置,可以设置`fetch`策略(如LAZY或EAGER),以及`cascade`属性来决定操作的级联性。例如,一个部门可以有多个员工,Department实体中有一个Employee列表。 3. **多对一映射(Many-to-One...
### Hibernate关联映射的作用与常用属性详解 #### 关联映射概述 在对象关系映射(Object Relational Mapping,简称ORM)技术中,Hibernate作为Java领域内非常成熟且功能强大的框架之一,它允许开发者将Java类映射...
另外,使用`@LazyCollection(LazyCollectionOption.EXTRA)`或`@OneToMany(mappedBy ..., fetch = FetchType.LAZY)`可以实现懒加载,只在需要时加载子对象集合,减少内存消耗。 **六、总结** 理解并熟练掌握...
- `fetch`:决定如何加载关联数据,`FetchType.LAZY`表示延迟加载,`FetchType.EAGER`表示立即加载。 **多对一关系详解:** 与一对多相反,多对一关系是多个子类实例指向一个父类实例。在上面的用户和订单例子中,...