[jira] [Created] (METRON-1882) Refactor MapVariableResolver and Callers

["Otto Fowler (JIRA)" <ji...@apache.org>]

Otto Fowler created METRON-1882:
-----------------------------------

             Summary: Refactor MapVariableResolver and Callers
                 Key: METRON-1882
                 URL: https://issues.apache.org/jira/browse/METRON-1882
             Project: Metron
          Issue Type: Sub-task
            Reporter: Otto Fowler


from [~cestella]

 

"So, I guess I'm suggesting that this is like..3/4 of the way to a complete solution, which is for stellar to handle variable assignments completely.

Specifically, I'd say that our dominantly used variable resolver ({{MapVariableResolver}}) doesn't support updates, so nothing actually happens when you update outside of the {{DefaultVariableResolver}}, so assignments don't actually function yet and an error isn't thrown.
So, if someone reads the updated docs and uses {{++}} in the profiler or enrichments, it won't actually work and it'll not be apparent why.

What I'm suggesting is one of these:
 # refactoring the {{MapVariableResolver}} to support updates and refactoring the places where we use assignments to NOT handle variable assignment outside of stellar.
 # Making a feature branch for stellar assignments and I'd +1 this into that branch and we can do the final PR in that branch
 # pull back the scope of this PR and just have assignments supported in the parser without the unary operators. This is what I was getting here in my comment before:

{quote}For instance, in the BaseStellarProcessor class we have a parse method that returns the output of the expression. I'd suggest we have a parseExpression and parseAssignment where the first acts as it does now and the second returns the variable name and the result.
{quote}
Ultimately, I LOVE this PR and I don't want you to think that I'm poo-pooing it. I think this is great work and I look forward to the feature being added. It just seemed ALMOST done, but not quite enough to stand by itself in master because the gap may leave people confused."



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)