Narrow queried indices based on __typename filters#1229
Merged
marcdaniels-toast merged 1 commit intoJun 12, 2026
Merged
Conversation
myronmarston
requested changes
Jun 2, 2026
myronmarston
left a comment
Collaborator
There was a problem hiding this comment.
Nice work @marcdaniels-toast! Left some suggestions.
b48fcb7 to
223ddf6
Compare
myronmarston
requested changes
Jun 8, 2026
myronmarston
reviewed
Jun 8, 2026
myronmarston
reviewed
Jun 8, 2026
myronmarston
pushed a commit
that referenced
this pull request
Jun 12, 2026
…x_definitions (#1253) ## Summary Spun out of #1229 to ease review. This is just a rename; there are intentionally no behavior changes. Renames the `DatastoreQuery` field `search_index_definitions` to `initial_search_index_definitions` across all callers and tests, and adds a YARD doc describing it as "the index definitions as provided at construction, before any subsequent adjustments." The new name sets up a clear contrast with `narrowed_search_index_definitions` introduced in #1229, which derives a refined set based on query filters. > [!NOTE] > This could be a breaking change for ElasticGraph application maintainers, if their > application has any query interceptors that reference `query.search_index_definitions`. > The next release will need to be minor version bump (`v1.3.0`) and this should be > called out in the upgrade section of the release notes. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
When a query on an abstract type filters on `__typename`, we can skip
any index that contains none of the requested concrete types. For example,
querying `DistributionChannel` with `__typename: {equal_to_any_of: [PhysicalStore]}`
only needs to hit `physical_stores`, not `distribution_channels`.
`TypenameFilter` determines the subset of type names satisfying the
`__typename` filter using full set-algebra support across `not`, `any_of`,
and `all_of` combinators. `DatastoreQuery` uses this via
`narrowed_search_index_definitions`, which intersects
`initial_search_index_definitions` with only the indices that could
contain the filtered types.
Closes #1179
Generated with Claude Code
223ddf6 to
0b041fc
Compare
_typename filters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1179
When a query on an abstract type filters on
__typename, we can skip any index that contains none of the requested concrete types. For example, queryingDistributionChannelwith__typename: {equal_to_any_of: [PhysicalStore]}only needs to hitphysical_stores, notdistribution_channels.TypenameFilter(in theFilteringnamespace) extracts the set of type names satisfying the__typenamefilter, usingFilterValueSetExtractor.for_equalityfrom #1239 for full set-algebra support acrossnot,any_of, andall_ofcombinators.DatastoreQueryuses this vianarrowed_search_index_definitions, which intersectsinitial_search_index_definitionswith only the indices that could contain the filtered types.Note: the rename of
search_index_definitions→initial_search_index_definitionswas split into a separate prep PR (#1253) to ease review.Doc check
I wanted to be sure the YARD documentation of

initial_search_index_definitionsworked properly. Here's a screenshot: