-
Notifications
You must be signed in to change notification settings - Fork 254
Description
So JSONata is now the official AWS StepFunctions query language and that's great. It's also how I got to know and appreciate it.
To be usable in such a context it has (justifiably) lost $eval() (in lieu of which AWS provides $parse(), to deserialize strings containing inert JSON). I am not mourning $eval as I am generally against dynamic parsing / recursive interpreter invocations, for inevitably introducing security / reliability problems in production-grade environments.
However, barring $eval and with JSONata's design choice that a regex/pattern is a function, it seems there is no way to convert an inert JSON string such as "^s3://my-bucket/" to a regular expression that can be matched against a runtime string.
(I am ignoring, of course, the theoretical possibility of using JSONata's Turing completeness to implement a regular-expression matching engine 😕).
Equivalently, without $eval (arguably, even with it), JSONata's regex support seems to be intended for literal expressions only, and is mostly incapable of programmatic manipulation of regular expressions (e.g. combine $prefix and $suffix to create "^" & $prefix & ".*" & $suffix & "$"), which is possible and useful in many contexts.
Here's one possible, fairly straightforward solution ( = enhancement request):
-
$prefix_re := $regex("s3://my-bucket/")
same as/s3:\/\/my-bucket\//, no need to escape the all-too-common slash -
$suffix_re := $regex($regex_escape(user_provided_suffix))
$regex_escape()is pretty essential too -
$prefix_re_source := $prefix_re()
would be nice if this returns"^s3://my-bucket/"rather than** no match ** -
$full_uri_re := $regex("^" & $prefix_re() & ".*" & $suffix_re() & "$")
regex compounding -
user_provided_uris[$contains($full_uri_re)]
compound, non-literal regex used like any other regex
Would be glad to hear people's opinions on this.