[Question] Regex based node selection from the JSON

[manikyab]

I want select nodes based on a starting pattern. Can you please help me with the JSON PATH?

I am new to RFC9535 and JSON path

Thanks
Manikya

[jarangutan]

JsonPath includes a match and search function extension to help filter on arrays that allows regular expressions.

See this match query $..book[?match(@.category, "^r.*")] where ^r.* is a regular expression that looks for the starting character "r" followed by whatever.

Link to query in playground
Link to match function extension

Or see this search query $..book[?search(@.category, "^r")] where it does a substring search looking for the starting character to be "r"

Link to query in playground
Link to search function extension

[manikyab]

{ "CH_name": "Channel 1", "CH_id": 123, "status": "active" }
In the above JSON, I want to select all the elements which have keys starting with CH_
Every where it mentions I should use @property but I am unable to get results based on it.
My query is $[?search(@, "^CH_")]
@jarangutan thanks for the prompt reply

[theory]

@property is an extension of JSONPath not supported by RFC-9535. It does, however, support function extensions, provided in this implementation by the registry package. Alas, it only supports validation of values, not the selectors for those values.

I've thought for a while it might be useful to provide an implementation that passes the selector to a function, as well as the value. That would allow the function to examine the selector (in your case, an object property name) and return true only for those that start with CH_. The spec doesn't say anything about what can or should be passed to function extensions, so I think it would be okay. I should ask the authors. If they go for it, it would likely not be too much work to implement.

[manikyab]

I think it would be a great added feature because there are many use cases where we wanted to find a node which fits the certain rules.

[theory]

Finally posted to the mail list, but in the discussion realized that this won't work without additional syntax.

But one thing that the RFC has over the original design is support for object slices, so you can always select an explicit list of keys. In your example, that would be:

$['CH_name','CH_id']

Playground.

[jg-rp]

Hi @theory,

For what it's worth, in case you're tempted to implement some additional syntax, I've had a go at defining and implementing some non-standard JSONPath syntax that covers this use case here (TypeScript) and here (Python).

Essentially I use ~ as a keys/properties selector and # as a "current key identifier". See those links for examples and EBNF.

All the best,
James

[theory]

I think it would be pretty straightforward to add support for # as @jg-rp describes by changing the values that are passed around the executor from (current, root any), for the current node and the root node, to a struct:

type pathCtx struct {
	key     any
	root    any
	current any
}

Then setting key as appropriate in each Selector's Select method. Then it just needs a new AST object like LiteralArg that returns the value of ctx.key from its asValue() and evaluate() methods. The parse would then simply create this object when it encountered # in the appropriate context. Probably should have a flag to enable it, too, off by default.

Add support for accessing the key in a function is more difficult, because Select execution does not currently track the location, both because it's more resource-intensive (every node needs a copy of its parent's selectors) and because it's not otherwise required for filters. This makes the more typical use-case less memory--and-copy intensive (adding the above-described context would add just a single value to the context and never copy the whole normalized path).

SelectLocated does keep those copies, as required to report normalized paths for each node, but even it doesn't do so for filters. This is because, absent a feature as described here, the location isn't necessary until the filter completes execution and the code assembles the selected nodes with their assembled paths.

So, I'm inclined to support adding the additional key context to enable a feature like #, but not access to it from filters.