[
https://issues.apache.org/jira/browse/METRON-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773762#comment-15773762
]
ASF GitHub Bot commented on METRON-624:
---------------------------------------
Github user cestella commented on the issue:
https://github.com/apache/incubator-metron/pull/404
Hey, thanks for the great addition @jjmeyer0!
A few things to note and some context.
Around validation, the initial stellar implementation purposefully ran
validation the way that it's implemented, but we can reconsider those things if
we want.
* The variables resolve to `null` to ensure that functions could handle
`null` without error. I understand that Java and most programming languages
would NPE on `1 < null`, but our data flowing through the topologies will be
sparse, so not all variables will be defined for every message. If a stellar
statement is applied to a message where the variable is not defined, I wanted
to ensure that it did not fail, but rather did an appropriate thing depending
on the operation.
* We do function resolution during validation to ensure people have not
made a syntactic error in their stellar statements when pushing configs to
zookeeper. We would rather fail fast here.
Around `==` for floating point numbers. The initial stellar implementation
intended to do an epsilon check on equals involving doubles (e.g. Math.abs(lhs
- rhs) < epsilon) as you almost never want strict equality in floating point
numbers.
What this does show is that we need more of a rigorous spec and more time
spent on documenting the design of Stellar.
> Comparison Operators Evaluate Incorrectly
> -----------------------------------------
>
> Key: METRON-624
> URL: https://issues.apache.org/jira/browse/METRON-624
> Project: Metron
> Issue Type: Bug
> Reporter: Josh Meyer
> Labels: stellar
>
> Currently there is an issue with the way Stellar interprets comparison
> expressions. Currently it only compares numbers when both sides are numbers
> otherwise it converts both sides of the expression to a value and then
> compares them. Also, when looking at numbers it always gets double values to
> compare.
> Below is an example of a failing test that should pass.
> {code:theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=false}
> @Test
> public void compareNumberAndStringWithSameValueShouldFail() throws
> Exception {
> final Map<String, String> variableMap = new HashMap<>();
> assertFalse(runPredicate("1 == '1'", variableMap::get));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
