Add an ignoreMissing parameter to IngestDocument's removeField method #125232
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.
And use it in the
remove
processor.Related to #123891, and also this is a follow up to #124322 and #125051 (earlier nearby PRs that were laying the groundwork for this change).
Prior to this change, we had to traverse the document tree twice in the
remove
processor for each field that we wanted to remove: once to check whether the field existed (in thehasField
call), and then once to actually remove the field (in theremoveField
call). This was necessary becauseremoveField
would throw an exception if the field didn't exist, so the call had to be guarded. By adding anignoreMissing
parameter toremoveField
we can remove thehasField
-guarding and just specify that we don't care if the field doesn't exist (well, assumingignore_missing
has been set totrue
on the processor itself, which it typically is in the wild).I'm labeling this as a
>refactoring
since there's no user-visible change in behavior, I'm just twiddling the code a bit so that it happens to be faster. On which note, this speeds up theremove
processor by 30% -- I'm seeing that it's taking 290 microseconds per document rather than 413 onmain
(a further note: prior to #120573 it was taking 681 microseconds per document for the same benchmark).