java-client-api icon indicating copy to clipboard operation
java-client-api copied to clipboard

queryManager.uris does not honor additional-query in search options

Open marcopacurariu3 opened this issue 1 year ago • 6 comments

Version of MarkLogic Java Client API

6.5.0

Version of MarkLogic Server

11.0.2

Java version

JDK 17

OS and version

ProductName: macOS ProductVersion: 13.5 BuildVersion: 22G74

Input: Some code to illustrate the problem, preferably in a state that can be independently reproduced on our end

The current issue is a follow-up of this one: https://github.com/marklogic/java-client-api/issues/1640

In the last issue you correctly mentioned that the correct format for search positive/negative is: positive-query and negative-query

However, the way I created the last issue is not 1:1 with the issue that we actually had. Our issue is actually the following: executing a search query and passing an options name parameter (where the options contains an and-not-query looking for a collection is simply ignored in QueryBatcher, but it works for a simple search).

Let me help you a bit with a piece of code:

QueryManager queryManager= markLogicDatabaseClient.newQueryManager();
        final RawCombinedQueryDefinition structQueryDef = queryManager
            .newRawCombinedQueryDefinition(new StringHandle(
                "<search xmlns=\"http://marklogic.com/appservices/search\">\n" +
			"  <query>\n" +
			"    <and-query>\n" +
			"      <term-query>\n" +
			"        <text>world</text>\n" +
			"      </term-query>\n" +
			"    </and-query>\n" +
			"  </query>\n" +
			"</search>"), "all");

        final SearchHandle result = queryManager.search(structQueryDef, new SearchHandle());
        result.getMatchResults();

The content of "all.xml" contains (between other stuff):

<cts:and-not-query>
	  <cts:annotation type="searchable-collections"/>
	  <cts:positive>
	    <cts:collection-query>
	      <cts:uri>collection1</cts:uri>
	      <cts:uri>collection2</cts:uri>
	    </cts:collection-query>
	  </cts:positive>
	  <cts:negative>
	      <cts:collection-query>
		<cts:uri>ignoredCollection</cts:uri>
	      </cts:collection-query>
	  </cts:negative>
	</cts:and-not-query>

Actual output: What did you observe? What errors did you see? Can you attach the logs? (Java logs, MarkLogic logs)

The output is correct for a simple search, the collections are filtered, but for QueryBatcher they are not.

Expected output: What specifically did you expect to happen?

The output is the same for both search and QueryBatcher (collections are taken into account)

Alternatives: What else have you tried, actual/expected?

marcopacurariu3 avatar Feb 22 '24 14:02 marcopacurariu3

Thanks @marcopacurariu3 , we'll look at this soon too!

rjrudin avatar Feb 23 '24 18:02 rjrudin

@rjrudin, do you have any updates? Thanks! :)

marcopacurariu3 avatar Mar 11 '24 10:03 marcopacurariu3

@marcopacurariu3 I apologize for the delay - is all.xml your options file, and is that query in an additional-query element?

rjrudin avatar Mar 11 '24 12:03 rjrudin

I'm able to reproduce this if I include any sort of query in additional-query in search options. While calls to queryManager.search will honor that query, it appears that calls to the non-public queryManager.uris method do not, which is what DMSDK uses. This is true regardless of whether filtered is set to true or false when calling the uris method.

I am going to file a bug with the server. In the meantime, is it possible to include the additional-query in your client code instead of in search options?

rjrudin avatar Mar 11 '24 14:03 rjrudin

Captured via MLE-12777 as a server bug.

rjrudin avatar Mar 11 '24 14:03 rjrudin

Great, thanks for reproducing it. Please also let me know when it's fixed. In the meanwhile, yes, we found a workaround and we are not using the additional-query part from all.xml.

marcopacurariu3 avatar Mar 12 '24 14:03 marcopacurariu3