You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running convert-query on a field that uses a normalization function (ex. baseName(path)), the normalization function is not stripped from the converted query in a handful of queries. This can lead to issues down the road if the function is not found as expected.
To Reproduce
Steps to reproduce the behavior:
$ eqllib convert-query -s "Endgame Platform""registry where registry_value == '*foo*'"registry where baseName(key_path) == "*foo*"
This fails in particular because there is no translation rule for normalizing wildcard comparisons. If you were checking for foo with no wildcards, you'd get something like this, which is one case where normalization works as expected.
$ eqllib convert-query -s "Endgame Platform""registry where registry_value == 'foo'"registry where key_path == "*\\foo"
Expected behavior
Instead of linking to undefined functions, an exception should be raised, or the underlying field should be returned as is.
$ eqllib convert-query -s "Endgame Platform""registry where registry_value == '*blah'"registry where key_path == "*\\*blah"
The text was updated successfully, but these errors were encountered:
Describe the bug
When running
convert-query
on a field that uses a normalization function (ex.baseName(path)
), the normalization function is not stripped from the converted query in a handful of queries. This can lead to issues down the road if the function is not found as expected.To Reproduce
Steps to reproduce the behavior:
This fails in particular because there is no translation rule for normalizing wildcard comparisons. If you were checking for
foo
with no wildcards, you'd get something like this, which is one case where normalization works as expected.Expected behavior
Instead of linking to undefined functions, an exception should be raised, or the underlying field should be returned as is.
The text was updated successfully, but these errors were encountered: