-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Add support for flexible access pattern to NormalizeForStreamProcessor
#134524
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
Merged
elasticsearchmachine
merged 13 commits into
elastic:main
from
jbaiera:streams-fix-normalize-wip
Sep 12, 2025
Merged
Add support for flexible access pattern to NormalizeForStreamProcessor
#134524
elasticsearchmachine
merged 13 commits into
elastic:main
from
jbaiera:streams-fix-normalize-wip
Sep 12, 2025
Conversation
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
…ns about why it's breaking in the way it is
|
Pinging @elastic/es-data-management (Team:Data Management) |
|
Hi @jbaiera, I've created a changelog YAML for you. |
masseyke
approved these changes
Sep 12, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
mridula-s109
pushed a commit
to mridula-s109/elasticsearch
that referenced
this pull request
Sep 17, 2025
…or` (elastic#134524) Fixes field querying and writing logic for NormalizeForStreamProcessor so that it can function on both `classic` and `flexible` ingest pipeline access patterns. NormalizeForStreamProcessor was added in elastic#125699 with support for the default ingest node field access logic (now known as `classic` mode). We have since added support for the `flexible` access pattern in ingest pipelines, which allows for querying dotted field names and writing dotted field names when parent path elements are missing. The NormalizeForStreamProcessor was written with the classic access pattern in mind. The processor was designed to look for singular field names and to rely on the classic field writing logic which creates intermediate parent objects when setting a value that is nested in the document. When flexible mode was enabled, the logic did not anticipate dotted field names that could be inconsistently accessible from the source map at certain points in the path notation. Further, the flexible access pattern does not create intermediate parent objects like before. A secondary renaming method was added to take these changes into account.
gmjehovich
pushed a commit
to gmjehovich/elasticsearch
that referenced
this pull request
Sep 18, 2025
…or` (elastic#134524) Fixes field querying and writing logic for NormalizeForStreamProcessor so that it can function on both `classic` and `flexible` ingest pipeline access patterns. NormalizeForStreamProcessor was added in elastic#125699 with support for the default ingest node field access logic (now known as `classic` mode). We have since added support for the `flexible` access pattern in ingest pipelines, which allows for querying dotted field names and writing dotted field names when parent path elements are missing. The NormalizeForStreamProcessor was written with the classic access pattern in mind. The processor was designed to look for singular field names and to rely on the classic field writing logic which creates intermediate parent objects when setting a value that is nested in the document. When flexible mode was enabled, the logic did not anticipate dotted field names that could be inconsistently accessible from the source map at certain points in the path notation. Further, the flexible access pattern does not create intermediate parent objects like before. A secondary renaming method was added to take these changes into account.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
auto-merge-without-approval
Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!)
>bug
:Data Management/Ingest Node
Execution or management of Ingest Pipelines including GeoIP
Team:Data Management
Meta label for data/management team
v9.2.0
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.
Fixes field querying and writing logic for NormalizeForStreamProcessor so that it can function on both
classicandflexibleingest pipeline access patterns.NormalizeForStreamProcessor was added in #125699 with support for the default ingest node field access logic (now known as
classicmode). We have since added support for theflexibleaccess pattern in ingest pipelines, which allows for querying dotted field names and writing dotted field names when parent path elements are missing.The NormalizeForStreamProcessor was written with the classic access pattern in mind. The processor was designed to look for singular field names and to rely on the classic field writing logic which creates intermediate parent objects when setting a value that is nested in the document. When flexible mode was enabled, the logic did not anticipate dotted field names that could be inconsistently accessible from the source map at certain points in the path notation. Further, the flexible access pattern does not create intermediate parent objects like before. A secondary renaming method was added to take these changes into account.