Skip to content

[Feature request] Highlighting with parent/child queries #1764

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

Closed
Vineeth-Mohan opened this issue Mar 6, 2012 · 6 comments
Closed

[Feature request] Highlighting with parent/child queries #1764

Vineeth-Mohan opened this issue Mar 6, 2012 · 6 comments
Labels
discuss :Search Relevance/Highlighting How a query matched a document Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch

Comments

@Vineeth-Mohan
Copy link

docID and the highlighted part of the matched document needs to be given back.

Requirement

On the query side, we would specify we want the children to be returned along with their parent data, and optionally some highlighting on the children fields.

{
    "query": {
        "top_children" : {
            "type": "subcontent",
            "query" : {
                "term" : {
                    "name" : "bike"
                }
            }
            "score" : "max",
            "factor" : 5,
            "incremental_factor" : 2
        }
    },
    "children": {  // just having this tags means we at least want the ids of the children
        "size" : 2, // maximum number of children by parent to return
        "full_data" : false, // if true return not just the id of the child but also its data
        "highlight" : { // same syntax as for normal queries
            "fields" : {
                "name" : {}
            }
        }
    }
}

Then as results we would have something like:

"hits" : {
    "total" : 7,
    "max_score" : 3.366573
    "hits" : [
        {
            "_index" : "es",
            "_type" : "twitter",
            "_id" : 8001,
            "_score" : 3.366573,
            "children": {
                "total" : 4,
                "hits" : [ // hits on children of this current parent, ordered by score
                    {
                        "_id" : 654,
                        "highlight" : {
                           "name" : [ "my lovely <em>bike</em>" ]
                         }
                    },
                    {
                        "_id" : 987,
                        "highlight" : {
                           "name" : [ "my nice <em>bike</em>" ]
                         }
                    }
               ]
            }
        },
        {
            "_index" : "es",
            "_type" : "twitter",
            "_id" : 8004,
.... etc....
}

Efforts in this direction is documented here - http://elasticsearch-users.115913.n3.nabble.com/Highlighting-with-parent-child-queries-td3275351.html

@srijiths
Copy link

srijiths commented Mar 7, 2012

Very usefull feature

@siminoushad
Copy link

i also feel this feature quite usefull . +1

@shyam0586
Copy link

I also love to see this one in action . +1

@febintt
Copy link

febintt commented Mar 7, 2012

This is one killer feature . +1

@Vineeth-Mohan
Copy link
Author

@kimchy - Is there update to this issue. Do you think this is feasible in any close future ?

@clintongormley
Copy link
Contributor

This will be possible with the top_hits aggregation once parent-child aggs are supported.

@javanna javanna added the Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch label Jul 16, 2024
tvernum added a commit that referenced this issue Feb 25, 2025
This changes `SecurityIndexManager` so that it is aware of projects, and
can deal with indices in each project having different states
(`.security` exists in some projects, but not others, has unavailable
shards in one project, etc).

The design is that the `SecurityIndexManager` handles all projects, and
has a single listener for cluster state events. It tracks the state of
the applicable security index in each individual project.

Methods that enquired about the state of an index have been move from
`SecurityIndexManager` itself to the inner class
`ProjectSecurityIndex`.

Callers now need to obtain a reference to the correct
`ProjectSecurityIndex` via either:
- `getProject(ProjectId)` _or_
- `forCurrentProject` (which relies on the `ProjectResolver`).

One side effect of this is that some calls that previously would have
seen the "live" state of the security index (i.e. state as at last
cluster change event) may now see something that is a millisecond or 2
old because `ProjectSecurityIndex` retains a point in time view of the
index state.
For the most part this is a benefit as it ensures that a series of
decisions about the state oif the index are made from a consistent view
of that state. The previous implementation has a `defensiveCopy` method
that was intended to be used for this purpose, but its use was optional
and not consistent.
tvernum added a commit that referenced this issue Feb 25, 2025
This unmutes a number of security-related YAML tests that correctly
function now that we have merged the following PRs

- #1752
- #1755
- #1764 
- #1771
- #1772
- #1775
- #1782
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss :Search Relevance/Highlighting How a query matched a document Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch
Projects
None yet
Development

No branches or pull requests

7 participants