- 浏览: 208367 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
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 1209solr/home是solr实例化core核的依据和入口,是必 ... -
CronTrigger Tutorial
2011-02-24 18:58 872转载地址:http://www.quartz-schedule ... -
事务未正确关闭引起的HIBERNATE SESSION不能正确关闭
2010-10-30 13:46 1624问题现象: 第一 ... -
hibernate 四种抓取策略
2010-10-24 10:42 893转载:http://www.cnblogs.com ... -
cas分析
2010-05-10 13:20 1952Central Authentication Service ... -
FCKeditor2.6.5及后续版本 for PHP配置及中文上传乱码解决!
2009-12-10 13:37 1376对于Fckeditor上传中文名文件时显示乱码的问题,现公布方 ... -
xpath语法
2009-10-12 21:02 889转载:http://www.w3schools.com/XPa ... -
jstl标签中循环map
2009-10-12 20:58 2553<% Map map = new HashMap(); ... -
log4j输出多个自定义日志文件(分离日志)
2009-06-24 11:30 2563转载: http://wangjc-opal.iteye.co ... -
错误: 必须限制口令文件读取访问
2008-10-10 17:06 3062转载:http://hi.baidu.com/lifecodi ... -
spring AOP使用结总结
2008-09-12 14:23 1070AOP使用结总结 最近需要 ... -
log4j手动加载配置文件
2008-09-10 15:26 3136PropertyConfigurator.configur ... -
spring集成hibernate使用缓存简单实例
2008-07-08 18:20 2304这部分为转载:http://www ... -
lucene应用入门1
2008-07-06 16:49 2111简单的建立索引和索引 ... -
多对多查询的条件设置和删除问题
2008-07-03 14:50 1467select 父 from 父类 父 left join 父. ... -
DOM4J学习笔记
2008-07-01 15:07 3673DOM4J简单介绍 基本使用 读取XML文档 Import o ... -
延迟初始化错误(转载)
2008-06-12 17:52 980转载地址:http://lz726.ite ... -
UUID [转帖]
2008-05-20 15:25 891/***********本人原创,欢迎转载,转载请保留本人信息 ... -
一段简单的发送邮件代码
2008-04-28 15:57 1013package send; import java. ... -
HIBERNATE2 CLOB字段延迟加载办法[转载]
2008-04-18 13:49 3056[转载]http://callan.iteye.com/blo ...
相关推荐
Hibernate fetch lazy cascade inverse 关键字
正确理解hibernate fetch 的作用
Hibernate环境搭建 Hibernate主要接口 Hibernate主要映射 Hibernate的lazy、fetch、cascade等策略 Hibernate性能优化
主要介绍了hibernate 中 fetch=FetchType.LAZY 懒加载失败处理方法,需要的朋友可以参考下
hibernate的类级别检索策略和检索策略的lazy、fetch、batch-size属性使用
http://blog.csdn.net/e421083458/article/details/8794127 该源码为Hibernate教程配套源码
该资源包括了hibernate开发中的常见关联映射的源代码,其中包括:one2one,one2many,many2many等,还有继承映射,inverse,fetch,cascade关键字的应用等,对初学者来说,是很实用的,难度适中,很好理解
<set name="emps" inverse ="true" lazy="true" cascade="none" batch-size="2" fetch="join" > </hibernate-mapping> Hibernate映射多对一: public class Emp implements java.io.Serializable {...
中取出的记录条数,一般设置为30、50、100.Oracle数据库的JDBC驱动默认的Fetch Size=15,设置Fetch Size设置为:30、50,性能会有明显提升,如果继续增大,超出100,性能提升不明显,反而会消耗内存。 即在...
19.1.7. 使用延迟属性抓取(Using lazy property fetching) 19.2. 二级缓存(The Second Level Cache) 19.2.1. 缓存映射(Cache mappings) 19.2.2. 策略:只读缓存(Strategy: read only) 19.2.3. 策略:读/...
主要介绍了javascript实现fetch请求返回的统一拦截,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
16.3.5 用带子查询的select语句整批量初始化orders集合(fetch属性为“subselect”) 16.3.6 迫切左外连接检索(fetch属性为“join”) 16.4 多对一和一对一关联的检索策略 16.4.1 迫切左外连接检索(fetch...
我把fetch star的2.0的项目用3.8重做了一遍 意在学习参考交流
Hibernate配置各种数据源 <hibernate-configuration> <!– 各属性的配置–> <!—为true表示将Hibernate发送给数据库的sql显示出来 –> ”show_sql”>true <!– SQL方言,这边设定的是MySQL –> ”dialect”>...
19.1.7. 使用延迟属性抓取(Using lazy property fetching) 19.2. 二级缓存(The Second Level Cache) 19.2.1. 缓存映射(Cache mappings) 19.2.2. 策略:只读缓存(Strategy: read only) 19.2.3. 策略:读/...
fetch请求超时,在fetch的基础上做的可以设置超时时间的 javascript 插件,具体使用请查看我的博客 https://blog.csdn.net/yumikobu/article/details/80167982
@Basic(fetch = FetchType.LAZY) String getDetailedComment() { ... } // persistent property @Temporal(TemporalType.TIME) java.util.Date getDepartureTime() { ... } // persistent property @Enumerated(Enum...
iOS 7学习:多任务处理之Background Fetch对应的Demo,已经修正不断Background Fetch中出现的多线程锁问题。
Fetch Robot