Utility of the "DOT" matcher `%` for `matching? #115

New issue

Open

opened 2025-08-29 09:01:59 +00:00 by mih · 1 comment

mih commented

2025-08-29 09:01:59 +00:00

(Migrated from github.com)

Is there any use case that does NOT require wrapping any search string in % to get any sensible hits?

If the feature is later extended to only match against values, would the matching term be matched against the start and end of individual values? Or a concatenation of values?

If the latter, the question above stands also then.

If the former, what would be the syntax to limit the matching to a particular (subset of) keys?

Right now, the matching is done against the JSON string form of an entire record. All use cases I can think of would want to match against values of a key, never a key directly. Any JSON record would not have a predictable order also. Is there any use case that does NOT require wrapping any search string in `%` to get any sensible hits? If the feature is later extended to only match against values, would the `matching` term be matched against the start and end of individual values? Or a concatenation of values? If the latter, the question above stands also then. If the former, what would be the syntax to limit the matching to a particular (subset of) keys?

christian-monch commented

2025-09-02 07:07:59 +00:00

(Migrated from github.com)

Right now, the matching is done against the JSON string form of an entire record. All use cases I can think of would want to match against values of a key, never a key directly. Any JSON record would not have a predictable order also.

The value-based match is implemented in the open PR #123

Is there any use case that does NOT require wrapping any search string in % to get any sensible hits?

Hard to say. It might be interesting to find all records with a certain prefix.

If the feature is later extended to only match against values, would the matching term be matched against the start and end of individual values? Or a concatenation of values?

PR #123 implements matching against individual values.

If the latter, the question above stands also then.

If the former, what would be the syntax to limit the matching to a particular (subset of) keys?

A possible syntax (PR #123 does not implement key subsets and does not define a syntax) would be <key>=<value>. Another way to specify key-specific searches would be to post a search-spec to the endpoint. The search-spec could be a JSON dictionary with <key>: <pattern> entries.

One issue would be the <key>-spec. Because records have a tree structure, we need a path-syntax for keys. That is not a problem, but the performance impacts of such an approach are not yet determined.

> Right now, the matching is done against the JSON string form of an entire record. All use cases I can think of would want to match against values of a key, never a key directly. Any JSON record would not have a predictable order also. > The value-based match is implemented in the open PR #123 > Is there any use case that does NOT require wrapping any search string in `%` to get any sensible hits? > Hard to say. It might be interesting to find all records with a certain prefix. > If the feature is later extended to only match against values, would the `matching` term be matched against the start and end of individual values? Or a concatenation of values? PR #123 implements matching against individual values. > > If the latter, the question above stands also then. > > If the former, what would be the syntax to limit the matching to a particular (subset of) keys? A possible syntax (PR #123 does not implement key subsets and does not define a syntax) would be `<key>=<value>`. Another way to specify key-specific searches would be to post a search-spec to the endpoint. The search-spec could be a JSON dictionary with `<key>: <pattern>` entries. One issue would be the `<key>`-spec. Because records have a tree structure, we need a path-syntax for keys. That is not a problem, but the performance impacts of such an approach are not yet determined.