Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marcopacurariu3 opened this issue Feb 22, 2024 · 6 comments
Open

Comments

@marcopacurariu3
Copy link

marcopacurariu3 commented Feb 22, 2024

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: #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?

@rjrudin
Copy link
Contributor

rjrudin commented Feb 23, 2024

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

@marcopacurariu3
Copy link
Author

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

@rjrudin
Copy link
Contributor

rjrudin commented Mar 11, 2024

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

@rjrudin
Copy link
Contributor

rjrudin commented Mar 11, 2024

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 rjrudin changed the title cts:and-not-query (positive and negative) is ignored in QueryBatcher queryManager.uris does not honor additional-query in search options Mar 11, 2024
@rjrudin
Copy link
Contributor

rjrudin commented Mar 11, 2024

Captured via MLE-12777 as a server bug.

@marcopacurariu3
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants