ingest: extended if documentation
#35044
Conversation
jakelandis
added
>docs
|
Pinging @elastic/es-core-infra |
jakelandis
changed the title
if documentation
|
cc @jdconrad since this is partly an introduction to using Painless |
There was a problem hiding this comment.
Left a few remarks :) Generally looks fine (and very useful for users). I'm just a little worried, we're now using the conditionals docs to make up for shortcomings in the Painless docs? (this is really good stuff though, maybe it should just be moved to the painless docs where it gets too general?)
| to `true` or `false`. | ||
|
|
||
| For example the following processor will <<drop-processor,drop>> the document | ||
| (e.g. not index it) if the input document has a field named `network_name` |
There was a problem hiding this comment.
e.g. -> i.e. I think?
There was a problem hiding this comment.
fixed, thanks. (i always mix up those two)
| level `b` object. | ||
|
|
||
| To help protect against NullPointerExceptions, null safe operations should be used. | ||
| Fortunately Painless makes {painless}/painless-operators-reference.html#null-safe-operator[null safe] |
There was a problem hiding this comment.
I think this needs a comma right? Fortunately,
| // TESTRESPONSE | ||
| //// | ||
|
|
||
| The source document can also use dot delimited fields to represent nested fields. |
There was a problem hiding this comment.
I'm not so sure about this section. It's a nice explanation of the dot expander processor, but it seems to get a little off-topic? (it just seems to be a very specific example and I don't see how it's any different from explaining that you could use another script processor before your if to do a transformation on your doc before evaluation the conditional)
There was a problem hiding this comment.
The section is titled Handling Nested Fields in Conditionals and wanted to include this since it is (imo) not obvious. Admittedly this ended up more of handling null references section and it is abit out of place.
I don't have strong opinions of keeping it or tossing it, but lets see @acchen97 says about it's usefulness. If input documents are rarely in dot syntax then we should toss this, if it is common we can discuss how to integrate it better.
| running in the {painless}/painless-ingest-processor-context.html#null-safe-operator[ingest processor context] | ||
| can be used to determine if the condition should evaluate to `true` or `false`. | ||
|
|
||
| IMPORTANT: Values in an `if` condition are read-only and may not change any |
There was a problem hiding this comment.
NIT: Wouldn't just: "The value of ctx is read-only in if conditions. Trying to mutate it will throw and Exception." be cleaner? (because it's not "values" that are read-only but just ctx)
There was a problem hiding this comment.
yup, i like your suggestion... updated.
| IMPORTANT: Values in an `if` condition are read-only and may not change any | ||
| values of `ctx`. | ||
|
|
||
| A more complex `if` condition that drops the document (e.g. not index it) |
There was a problem hiding this comment.
e.g. => i.e. again right?
| -------------------------------------------------- | ||
| // CONSOLE | ||
|
|
||
| The conditional needs to be all on one line since JSON does not |
There was a problem hiding this comment.
This seems like it should be explained elsewhere. This is a very general fact about scripts.
There was a problem hiding this comment.
yeah, i really wanted the if conditional (script) to be readable on the page which requires the triple quote, but only wanted to provide a CONSOLE example that is valid JSON. Not sure how to achieve readability and valid JSON without having to repeat this fact.
|
The Painless scripts look fine to me. Thanks for the ping. |
part of #33188
@acchen97 - requesting your review since the
ifconditional enables new ingest patterns and wanted to get your feedback here. Let me know if you want me to upload the rendered doc somewhere.