hibernate 一对多 查询问题

Posted 2023-05-05

product物品表，photo物品照片表，一个物品对应5张照片

双向关联映射已经做好了，查product的时候用的criteria条件查询

怎么在查 所有的 product的时候，同时把每个product对应的一张photo也查出来 ？
代码在这里
http://blog.csdn.net/neosmemory/archive/2011/06/10/6535968.aspx

你不是已经做好映射了?直接取出就ok了.
你在product类中声明一个set类型的变量,存储类型为photo类型
在你的xxx.hib.xml中配置出这个<set>映射
然后在你查询product,调用里面的那个set变量,hibernate就会自动关联到photo表..追问

做好了，也许会有点问题，刚才有报懒加载异常
问题说不清，能帮我看看代码吗
http://blog.csdn.net/neosmemory/archive/2011/06/10/6535968.aspx

追答

你的photo类写getter/setter了吗?

追问

这些getter setter的就不贴了好吧，占篇幅。

追答

你的里的一对多:column列 对应的不是photo表中的goods_id外键吗?

追问

哦，谢谢你用心帮我，那里写错了，可页面上和action里怎么得到photoName

追答

你测试能运行出现结果吗?
你在action中是用lgoods来存储查询出的结果吗?
如果是的话,你在action中对lgoods进行getter/setter
然后在页面使用
//在这里调用action中的lgoods
//这里是goods的goodsname属性
//这里是你goods类中的photos Set.从photos中获取photo对象
//photo中的photoname属性

//在这里遍历 你的lgoods里面获取的

遍历.

-------------
其实你的dao类中的那个查询方法,可以直接使用一个万能查询方法..不用那么麻烦的.

追问

在action里可以拿到photoName了
action里用的是page存储查询结果
jsp页面里用来显示，物品id的都能拿到
我想应该嵌套查photoName，可是嵌套的这个 value里不知道写什么？ 写photos不好使，写page.content.photos也不好使，这东西对photos对象这种set类型不管用吗？

追答

//你的content中存放的是goods对象吧
//你不是可以直接使用吗,那肯定也可以直接用到goods中photos.
//那你直接遍历你的photos
//在这直接显示你的photoname

追问

应该是这样吧然后不过不管用
后来再action里加了 private Set photos = new HashSet(0);和它的getter setter
然后给photos赋page里的值
页面就有photos了，然后用你那个iterator就行了
谢谢你，花这么久的时间帮我解答。

参考技术A Product product =service.方法;(调用方法得到所需产品对象)
List<Photo> photo=prodduct.getphoto();//可得到该产品的所有照片集合，通过对象"."的方式取得照片

注意前提是，两表关系正确追问

关系应该配正确了，代码在这里，可以帮我看下不？
http://blog.csdn.net/neosmemory/archive/2011/06/10/6535968.aspx

参考技术B ？？？你的不是product中对应的照片是多张吗？应该是取出一个product对象里面包含的photo对象的集合，就是product数据库表中对照片的外键引用的字段，在hibernate做映射时，体现为一个集合。你查询出product时会同时查询出photo集合，不过你不应该用criteria，直接hql语句就行了。很方便。希望对你有帮助追问

一个物品去查它的图片明白怎么做，
一分页查所有物品就不会了，能帮我看看代码吗
http://blog.csdn.net/neosmemory/archive/2011/06/10/6535968.aspx

参考技术C 你通过查询course可以得到一个course的对象（courseObj）, 然后courseObj.hihernate一对多关联映射（单向Classes-Student）一对多关联映射利用了多对一 参考技术D 什么criteria啊 映射OK了 Hql 搞定了
select * from product a left join photo b on a.product_id=b.product_id追问

我问题没说不清，问题在这里
http://blog.csdn.net/neosmemory/archive/2011/06/10/6535968.aspx

hibernate一对多关系 在一方查询会获得重复数据，重复数量就是多端数据数量用@Fetch(FetchMode.SUBSELECT)解决

先来看数据表

版块表只有两个数据

板块1是推荐，下边没有子栏目

板块2下边有14个子栏目

在1的一端来查询，发现结果有16条

也就是板块1+版块2+版块2和他的14个子集都列出来了，这明显不对

 

板块对象的配置

    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    @JoinColumn(name = "sectionId")//ColumnMoDel中的外键，用于关联

 猜测了一下，是急加载导致的

查需语句为

Hibernate: 
    select
        this_.id as id1_17_1_,
        。。。。from
        t_section this_ 
    left outer join
        t_column columnmode2_ 
            on this_.id=columnmode2_.sectionId
Hibernate: 
    select
        columnmode0_.id as id1_7_,
       。。。。from
        t_column columnmode0_ 
    where
        columnmode0_.sectionid=‘1‘

 

 

删除这个策略配置为

 @OneToMany(cascade = CascadeType.ALL)
    @JoinColumn(name = "sectionId")//ColumnMoDel中的外键，用于关联

 

或者使用懒加载

 @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    @JoinColumn(name = "sectionId")//ColumnMoDel中的外键，用于关联

 

可以解决这个数据集重复的问题

但是，这样又获取不到多方的集合

看起来问题并不能这样解决

经过查询得知，使用 @Fetch可以解决这个问题

 @OneToMany(cascade = CascadeType.ALL)
    @JoinColumn(name = "sectionId")//ColumnMoDel中的外键，用于关联
    @Fetch(FetchMode.SUBSELECT)

 在控制台得知，发出的是两条查询

Hibernate: 
    select
        this_.id as id1_17_0_,
        。。。。。from
        t_section this_
Hibernate: 
    select
        columnmode0_.id as id1_7_,
       。。。。from
        t_column columnmode0_ 
    where
        columnmode0_.sectionid=‘1‘

如果注解再改一下

 @OneToMany(cascade = CascadeType.ALL,fetch = FetchType.EAGER)
    @JoinColumn(name = "sectionId")//ColumnMoDel中的外键，用于关联
    @Fetch(FetchMode.SUBSELECT)

语句又变了 

Hibernate: 
    select
        this_.id as id1_17_0_,
       。。。。from
        t_section this_
Hibernate: 
    select
        columnmode0_.sectionId as sectionI7_17_1_,
        。。。。from
        t_column columnmode0_ 
    where
        columnmode0_.sectionId in (
            select
                this_.id 
            from
                t_section this_
        )

 至于查询效率问题，目前暂无时间处理，有时间再用分析器测试，不过从语句上来分析，@Fetch(FetchMode.SUBSELECT)配合急加载肯定不如搭配懒加载快