Task #975 (assigned)
Opened 16 years ago
Last modified 14 years ago
Search.onlyType() can return different types
Reported by: | jamoore | Owned by: | jamoore |
---|---|---|---|
Priority: | critical | Milestone: | Unscheduled |
Component: | Search | Version: | 3.0-M1 |
Keywords: | hibernate search | Cc: | jburel, atarkowska, carlos@… |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
Under some circumstances:
Class[] klass = new Class[1]; klass[0] = TagAnnotation.class; search.onlyAnnotatedWith(klass); search.onlyType(Image.class); search.bySomeMustNone(new String[] { "an*" }, null, null);
can return more than images.
Change History (10)
comment:1 Changed 16 years ago by jmoore
- Status changed from new to assigned
comment:2 Changed 16 years ago by jmoore
search.onlyType(Experimenter.class); search.byFullText("root"); search.hasNext();
shows the same symptoms. The solution to this is fairly easy if poorly documented. See Hibernate Search 5.1.2.1. Even if using a criteria search one still needs the Class argument:
org.hibernate.Query fullTextQuery = fullTextSession.createFullTextQuery( luceneQuery, Customer.class );
However, the criteria is still loading the items, even if it's not returning them. This causes the SecurityViolation in the multi-user test.
comment:3 Changed 16 years ago by jmoore
comment:4 Changed 16 years ago by jmoore
And r2386
comment:5 Changed 16 years ago by jmoore
r2401 renames the boolean methods
comment:6 Changed 16 years ago by jmoore
- Cc jburel atarkowska carlos@… added
Jean-Marie, you'll have to tell me if this is needed for milestone:3.0-Beta3, but probably the best way to move forward with this is a completely different metaphor, which would also replace fetchAlso().
Instead, results could be built in phases:
search.onlyType(Image.class); search.bySomeMustNone(new String[] { "an*" }, null, null); // If results() or hasNext() or next() were called here, // then we'd have to do the sorting on the client, Instead: search.and(); search.byAnnotatedWith(new TagAnnotation()); // Chains the two invocations together. So that the results // will be the intersection of the two. or() and not() exist // as well. But we can also: search.and(); search.byHqlQuery( "select i from Image i left outer join fetch i.datasetLinks " + "where i.id in (:IDLIST)", null); // which uses the magic named parameter "IDLIST" to use all of the ids // that we've gathered to this point as the input to a regular // HQL query, which will do all the fetch for us. // Now we can call: search.results();
Thoughts?
comment:7 Changed 16 years ago by jburel
We can keep it as it is for now.
I won't have time to modify the code.
I don't like the HQL Approach for the standard types i.e. image/dataset/project etc. We should hide that from the dev. at least for those types.
For sure, as it is, it is not practical to work with it but I won't take any risks for Beta3
comment:8 Changed 16 years ago by jmoore
- Milestone changed from 3.0-Beta3 to 3.0-Beta4
Ok. Pushing this to milestone:3.0-Beta4, even if it is more of a point release issue. As for the HQL for PDI, let's discuss that elsewhere. I don't think we can start putting methods for handling individual hierarchies in this interface. (Named queries is probably the way to go.)
comment:9 Changed 15 years ago by jmoore
- Milestone changed from OMERO-Beta4 to OMERO-Beta4.1
Planning on revamping search in 4.1
comment:10 Changed 14 years ago by jmoore
- Type changed from Bug to Task
When the related TagAnnotation is private and belongs to another user, a SecurityViolation is thrown: