axosyslog icon indicating copy to clipboard operation
axosyslog copied to clipboard

Filterx function path lookup

Open bshifter opened this issue 11 months ago • 1 comments

Add path_lookup to the filterx_object Namespace as an Alternative to get_subscript

This PR introduces a new function, path_lookup, to the filterx_object namespace. It allows retrieving elements from nested filterx lists or dictionaries in a single call, providing a more convenient and expressive alternative to using get_subscript repeatedly.

Key Features:

  • Flexible First Argument: The first argument must be a list or dictionary. Mixed structures (e.g., nested combinations of lists and dictionaries) are fully supported.
  • Dynamic Path Lookup: The second parameter accepts a list literal containing both filterx strings (for dictionary keys) and integers (for list indices).
  • Deep Nested Access: Enables seamless access to deeply nested elements in hybrid list-dictionary structures.
  • Reverse Indexing Support: Integer indices support negative values for reverse indexing in lists, mirroring Python-like behavior.

example:

filterx {
d = {"foo":1,"bar":[3,2,1],"baz":{"tik":"tak"}};
a = path_lookup(d, ["bar", 0]); # returns 3
b = path_lookup(d, ["baz", "tik"]); # returns "tak"
c = path_lookup(d, ["bar", -1]); # returns 1
}

bshifter avatar Jan 08 '25 20:01 bshifter

It would be great if we could delegate literal/string only paths to the underlying FilterXObject for an improved performance.

e.g. instead of just a getattr method, we would have a getpath method as well, which by default would implement the "generic" path_lookup case as you implemented it, but we would have an option to delegate it to the underlying object.

The ultimate goal would be to avoid having to wrap/unwrap the embedded JSON objects as return values, we could just iterate over string keys within object-json-object.c and then return the end result.

There's just one thing we should consider, #385 seems to improve the time to return embedded dict objects, if that proves to be a good substitute, then the existing series of getattr calls should not be a problem that much anymore.

bazsi avatar Jan 22 '25 10:01 bazsi

#746 introduces the setter side with a different syntax. We should implement the getter side later based on this PR, but following the new syntax.

MrAnno avatar Aug 22 '25 15:08 MrAnno

pyth

MrAnno avatar Aug 25 '25 12:08 MrAnno