Conversation
|
It turns out there's a bug in the library which prevents this configuration from being respected in all cases, which I have fixed in a PR to the library. Converting to draft until it's been released. |
There was a problem hiding this comment.
this is a behaviour change - it used to throw on missing paths (which I believe was unintended) and now returns NaN
There was a problem hiding this comment.
this bug was fixed
Codecov Report
@@ Coverage Diff @@
## master #7819 +/- ##
============================================
+ Coverage 69.99% 71.38% +1.38%
- Complexity 4303 4307 +4
============================================
Files 1616 1617 +1
Lines 83752 83830 +78
Branches 12514 12520 +6
============================================
+ Hits 58619 59838 +1219
+ Misses 21109 19922 -1187
- Partials 4024 4070 +46
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
eae796c to
333e71c
Compare
f8ea01f to
ed3996e
Compare
Jackie-Jiang
left a comment
There was a problem hiding this comment.
Thanks for contributing the fix to the json-path library!
In JsonFunctions.java I can still see some method throwing JsonProcessingException. Should it be eliminated completely?
pinot-common/src/main/java/org/apache/pinot/common/function/scalar/JsonFunctions.java
Outdated
Show resolved
Hide resolved
pinot-common/src/main/java/org/apache/pinot/common/function/scalar/JsonFunctions.java
Outdated
Show resolved
Hide resolved
No, the values may not be valid json, or it may not be possible to stringify. The exceptions not thrown now were thrown because a jsonpath didn’t match the document. |
… exceptions being thrown
75e016e to
19d3ea5
Compare
By default, when a JSON path doesn't match a document, the JSONPath library throws an exception, but this can be disabled with configuration. These exceptions can be quite costly during ingestion and are worth avoiding:

The
JsonScalarExtractTransformFunctionalready uses this configuration.