saperliu / hibernate-generic-dao

Automatically exported from code.google.com/p/hibernate-generic-dao
0 stars 0 forks source link

Trouble resolving nested fetch relationships #56

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
using v0.5.0 of trg_search-hibernate

I have a complex Entity that contains two child entities, of which each
child has entities.  I want to force a few of the nested entities to be
eagerly fetched.

if I do
s.addFetch("entity2");
s.addFetch("entity3");
s.addFetch("entity3.entity4");

the first two fetches work as expected, but when resolving the third fetch,
the getAlias method is returning the wrong alias.

This is what is generated (approximately, since I just modified the real
output):
select _it from com.mycompany.Entity1 _it left join fetch _it.entity2 as
a2_entity2 left join fetch _it.entity3 as a3_entity3 left join fetch
_it.entity4 as a4_entity4

However, I was expecting it to be:
select _it from com.mycompany.Entity1 _it left join fetch _it.entity2 as
a2_entity2 left join fetch _it.entity3 as a3_entity3 left join fetch
a3_entity3.entity4 as a4_entity4

Notice the change of the alias of the entity4 property.

I believe the problem is in the getAlias() method, but I'm not fully sure
what it was trying to accomplish and I don't want to break something else.

Original issue reported on code.google.com by chuckdea...@gmail.com on 3 Dec 2009 at 5:23

GoogleCodeExporter commented 9 years ago
Just taking a stab at the solution (which works for me, BTW)

In BaseSearchProcessor.getAlias(), I made a small change to the following block:

else if (ctx.aliases.containsKey(path)) {
    AliasNode node = ctx.aliases.get(path);
    if (setFetch) {
        AliasNode parent = node;
        while (parent.parent != null) {
            parent.fetch = true;
            parent = parent.parent;
        }
    }

    return node;
}

My understanding of this code block is that it wants to set the fetch property 
for
all of this nodes ancestors.  In this revised code, it still does that, but 
doesn't
reuse the node variable.

Original comment by chuckdea...@gmail.com on 3 Dec 2009 at 5:41

GoogleCodeExporter commented 9 years ago
Thanks for the report and solution. I'll look into this soon to get your 
solution or 
something similar into the codebase for the next release.

Original comment by dwolvert on 4 Dec 2009 at 3:32

GoogleCodeExporter commented 9 years ago
Here is the solution in patch form against current svn (07JUN2010). Which also 
seems
to be working in 0.5.1.

Index: 
search/src/main/java/com/googlecode/genericdao/search/BaseSearchProcessor.java
===================================================================
--- 
search/src/main/java/com/googlecode/genericdao/search/BaseSearchProcessor.java
(revision 649)
+++ 
search/src/main/java/com/googlecode/genericdao/search/BaseSearchProcessor.java
(working copy)
@@ -900,9 +900,10 @@
        } else if (ctx.aliases.containsKey(path)) {
            AliasNode node = ctx.aliases.get(path);
            if (setFetch) {
-               while (node.parent != null) {
-                   node.fetch = true;
-                   node = node.parent;
+               AliasNode parent = node;
+               while (parent.parent != null) {
+                   parent.fetch = true;
+                   parent = parent.parent;
                }
            }

Original comment by chuckdea...@gmail.com on 7 Jun 2010 at 5:55

GoogleCodeExporter commented 9 years ago
This patch works perfectly for me, thank you @chuckdeal97@gmail.com

Original comment by pltchu...@gmail.com on 19 Jun 2013 at 3:56

GoogleCodeExporter commented 9 years ago
version 1.0 has the same issue. I can confirm the patch resolves the issue. 
I'll try to contact owner and become contributor to resolve this.

Original comment by tom.monn...@gmail.com on 13 Nov 2013 at 10:21

GoogleCodeExporter commented 9 years ago
Would appreciate any help on where to put some tests for this.

Original comment by pablit...@gmail.com on 9 Jul 2014 at 7:21

GoogleCodeExporter commented 9 years ago
Issue 105 has been merged into this issue.

Original comment by pablit...@gmail.com on 9 Jul 2014 at 10:32