Skip to content

Enhance terms lookup query to take a query clause #18195

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

Open
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

srikanthpadakanti
Copy link
Contributor

@srikanthpadakanti srikanthpadakanti commented May 5, 2025

Description

Enhances the Terms lookup query to accept a query clause instead of only supporting a single docId. This expands functionality by enabling users to define document matches through flexible query logic rather than relying solely on fixed document IDs.

This change includes:

Support for Terms lookup query to use a query clause.
Validation logic to prevent using both id and query simultaneously.
Associated unit test updates to cover query-based lookup behavior.

Related Issues

Resolves #17599

Check List

  • [ X] Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Copy link
Contributor

github-actions bot commented May 5, 2025

❌ Gradle check result for 085edf2: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

github-actions bot commented May 9, 2025

❌ Gradle check result for edfa605: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

❌ Gradle check result for f7146ff: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

❌ Gradle check result for 90f90c7: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

❌ Gradle check result for 997ddbe: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

❌ Gradle check result for 9c85868: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

❌ Gradle check result for 6f52602: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions github-actions bot added enhancement Enhancement or improvement to existing feature or request Search:Query Capabilities labels May 15, 2025
…use rather than docId

Signed-off-by: Srikanth Padakanti <[email protected]>
Signed-off-by: Srikanth Padakanti <[email protected]>
Signed-off-by: Srikanth Padakanti <[email protected]>
…checks and updated unit tests

Signed-off-by: Srikanth Padakanti <[email protected]>
…checks and updated unit tests

Signed-off-by: Srikanth Padakanti <[email protected]>
…checks and updated unit tests

Signed-off-by: Srikanth Padakanti <[email protected]>
…checks and updated unit tests

Signed-off-by: Srikanth Padakanti <[email protected]>
Copy link
Contributor

❌ Gradle check result for 6ab5410: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

❌ Gradle check result for 101c8ad: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@srikanthpadakanti
Copy link
Contributor Author

@kotwanikunal @Bukhtawar @andrross @sandeshkr419
Can someone please review my PR.

Copy link
Contributor

✅ Gradle check result for 29c4d55: SUCCESS

Copy link
Contributor

❌ Gradle check result for ab7abdb: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?


public String id() {
return id;
out.writeOptionalWriteable(query);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to add in a version check here as well

Suggested change
out.writeOptionalWriteable(query);
if (out.getVersion().onOrAfter(Version.V_3_0_0)) {
out.writeOptionalWriteable(query);
}

@@ -90,6 +114,11 @@ public TermsLookup(StreamInput in) throws IOException {
if (in.getVersion().onOrAfter(Version.V_2_17_0)) {
store = in.readBoolean();
}
if (in.getVersion().onOrAfter(Version.V_3_0_0)) {
if (in.readBoolean()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you should be doing the in.readBoolean() explicitly.
ReadOptionalWriteable should take care of it for you.

Reference:

 public <T extends Writeable> T readOptionalWriteable(Writeable.Reader<T> reader) throws IOException {
        if (readBoolean()) {
            T t = reader.read(this);
            if (t == null) {
                throw new IOException(
                    "Writeable.Reader [" + reader + "] returned null which is not allowed and probably means it screwed up the stream."
                );
            }
            return t;
        } else {
            return null;
        }
    }

SearchResponse response;
try {
response = shardContext.getClient()
.search(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if there is a better location for fetching rather than rewrites. If I understand correctly, rewrite can be called multiple times through the query flow. We would have wasted search calls.

The actionGet() is also blocking the search thread on this query for a network call - which is not ideal.

Can we initialize this value at the start of the query creation and keep using the same value as a class var?
Also, can you please extract the query specific mechanism into a separate method for easy readability?

if (termsLookup != null && termsLookup.query() != null) {
QueryBuilder rewrittenQuery = termsLookup.query().rewrite(context);

SearchResponse response = context.getClient()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we store this value and reuse it for rewrite phases?
Also can we avoid blocking calls on the search thread?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this will need to be asynchronous, probably similar to how the current terms lookup query is implemented:

queryRewriteContext.registerAsyncAction((client, listener) -> fetch(termsLookup, client, ActionListener.map(listener, list -> {
supplier.set(list);
return null;
})));

@@ -6,6 +6,10 @@
<option name="HOST" value="localhost" />
<option name="PORT" value="5005" />
<option name="AUTO_RESTART" value="true" />
<RunnerSettings RunnerId="Debug">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please revert this change unless this is intentional.

if (termsLookup != null && termsLookup.query() != null) {
QueryBuilder rewrittenQuery = termsLookup.query().rewrite(context);

SearchResponse response = context.getClient()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this will need to be asynchronous, probably similar to how the current terms lookup query is implemented:

queryRewriteContext.registerAsyncAction((client, listener) -> fetch(termsLookup, client, ActionListener.map(listener, list -> {
supplier.set(list);
return null;
})));

@andrross andrross changed the title Feature request17599 Enhance terms lookup query to take a query clause May 20, 2025
@opensearch-trigger-bot
Copy link
Contributor

This PR is stalled because it has been open for 30 days with no activity.

@opensearch-trigger-bot opensearch-trigger-bot bot added the stalled Issues that have stalled label Jun 20, 2025
@vamshin
Copy link
Member

vamshin commented Jun 26, 2025

@srikanthpadakanti are you planning to continue working on this? We are targeting this feature for 3.2 release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or improvement to existing feature or request Search:Query Capabilities stalled Issues that have stalled
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request] Enhancing Terms lookup query to take a query clause rather than docId
4 participants