Search.onlyType() can return different types

[jmoore]

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.

[jmoore]

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)

[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.

[jmoore]

r2387

[jmoore]

And r2386

[jmoore]

r2401 renames the boolean methods

[jmoore]

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?

[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

[jmoore]

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.)