Combining different CEL expressions into a single expression

[josephschorr]

Apologies if I missed this in the documentation!

I have a set of pre-compiled CEL expressions, and I'd like to combine them into a new expression via logical operators such as and, or and not, producing a new combined expression to be run. Is there a capability for this somewhere in the CEL library?

[TristonianJones]

@josephschorr We've shied away from merging pre-compiled expressions since this tends to be error prone. I would recommend using the cel.AstToString method to convert your CheckedExpr values to human-readable strings that you stitch together with &&, ||, and ! before recompiling the combined expression. The only drawback of this approach is that it requires you to have setup the cel.NewEnv() in a way that makes it possible to stitch these expressions together and compile them again.

Your other alternative is to create aliases for the compiled expressions, e.g. lazyExprs map[string]cel.Ast and implement the interpreter.Activation in a way that when the name of the lazy expression is provided to Resolve(name string) that you would evaluate the expression and cache the result.

[josephschorr]

@TristonianJones As a followup, I realized that if I have the different subexpressions using the same variable names (but which refer to different values), the combined expression will be wrong. Is there a way to give AstToString some means to "rewrite" the names of vars using a map I define?

[TristonianJones]

@josephschorr to address that use case, you'd need to rewrite the variables before attempt to merge where there may be a conflict. The cel/inlining.go optimizer may be a good way to approach this.

[josephschorr]

@TristonianJones This works quite well for a single replacement, but I'm seeing the optimizer generate cel.bind(...) if a replaced variable is used more than once; is there a way to not have the system generate cel.bind and instead do a full replace of every usage?

[josephschorr]

Hi @TristonianJones,

Thanks for the pointers! I ended up just keeping my own tree of expressions and operators, and executing each expression on its own, stitching the boolean results together as I go along