Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #975 (assigned)

Opened 12 years ago

Last modified 10 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 12 years ago by jmoore

  • Status changed from new to assigned

When the related TagAnnotation is private and belongs to another user, a SecurityViolation is thrown:

ome.conditions.SecurityViolation: Cannot read ome.model.annotations.TagAnnotation
	at ome.security.basic.BasicACLVoter.throwLoadViolation(BasicACLVoter.java:84)
	at ome.security.ACLEventListener.onPostLoad(ACLEventListener.java:106)
	at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:204)
	at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
	at org.hibernate.loader.Loader.doQuery(Loader.java:729)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
	at org.hibernate.loader.Loader.doList(Loader.java:2213)
	at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
	at org.hibernate.loader.Loader.list(Loader.java:2099)
	at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94)
	at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569)
	at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)
	at org.hibernate.search.engine.QueryLoader.load(QueryLoader.java:79)
	at org.hibernate.search.query.FullTextQueryImpl.list(FullTextQueryImpl.java:244)
	at ome.services.search.FullText.doWork(FullText.java:154)

comment:2 Changed 12 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 12 years ago by jmoore

comment:4 Changed 12 years ago by jmoore

And r2386

comment:5 Changed 12 years ago by jmoore

r2401 renames the boolean methods

comment:6 Changed 12 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 12 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 12 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 11 years ago by jmoore

  • Milestone changed from OMERO-Beta4 to OMERO-Beta4.1

Planning on revamping search in 4.1

comment:10 Changed 10 years ago by jmoore

  • Type changed from Bug to Task
Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.119833 sec.)

We're Hiring!