json-valid PPL function

[kenrickyap]

Description

Based on this feature request: #3207

Added json_valid request.

### `JSON_VALID`

**Description**

`json_valid(jsonStr)` Evaluates whether a json-encoded string contains valid JSON syntax and returns TRUE or FALSE.

**Argument type:** STRING

**Return type:** BOOLEAN

Example:

    os> source=people | eval `valid_json` = json_valid('[1,2,3,4]'), `invalid_json` = json_valid('{"invalid": "json"') | fields `valid_json`, `invalid_json`
    fetched rows / total rows = 1/1
    +--------------+----------------+
    | valid_json   | invalid_json   |
    +--------------+----------------+
    | True         | False          |
    +--------------+----------------+

    os> source=accounts | where json_valid('[1,2,3,4]') and isnull(email) | fields account_number, email
    fetched rows / total rows = 1/1
    +------------------+---------+
    | account_number   | email   |
    |------------------+---------|
    | 13               | null    |
    +------------------+---------+

Related Issues

Resolves #3207

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[YANG-DB]

@kenrickyap can you please add the relevant documentation for this new function?

[kenrickyap]

@kenrickyap can you please add the relevant documentation for this new function?

Added doctest, integ-test, and unit tests

[LantaoJin]

what if the json_string is null? Could you add a test case for null

[acarbonetto]

I'm assuming null should return false?

[YANG-DB]

I'm assuming null should return false?

@acarbonetto yes I think it makes sense

[andy-k-improving]

If indeed null return false, then we should specify this behaviour on documentation to avoid any confusion,

[acarbonetto]

null returns null.

[acarbonetto]

Update: you are correct that null should return valse.
I've updated the tests and logic to match.

[YANG-DB]

missing license header

[YANG-DB]

actually why do we need 2 separate JsonUtils & JsonFunctions ?
would it make sense to unify into a single class ? (inside maybe the different namespaces)

[acarbonetto]

Excellent question. I dislike "utility classes" (what is the responsibility of a utility class?). But it gives us a central class to put all the json business logic. This seems to be how we do things (date time and IP address business logic also lives in util classes).

As for the JsonFunction class, it provides an integration layer between the language parser's function expressions and the json business logic. The casting expressions will be another class that will access the json logic.

This class could very well be named Json or JsonMapper. But if we do this, we should rename all the util classes in the utils package.

[andy-k-improving]

If indeed null return false, then we should specify this behaviour on documentation to avoid any confusion,

[currantw]

A few minor comments.

[currantw]

Can we extract the ObjectMapper as a static final class member?

[acarbonetto]

I'd rather not waste the memory unless a user is making json calls.
I think it's better to construct it each time its used.

[currantw]

Hmmm. What about the initialization-on-demand holder idiom? Agreed that it's probably better to avoid using the memory if it's not needed, but probably also good to avoid creating the same object hundreds of times if there are hundreds of calls to any JSON function? No need to address now either way, but maybe something to consider as JSON work progresses?