Github user cestella commented on the issue:
https://github.com/apache/metron/pull/1083
Sure, so the difference in the parser chaining example would be between the
following
# Stellar
```
"fieldTransformations" : [
{
"transformation" : "STELLAR"
,"input" : "pix_type"
,"output" : "logical_source_type"
,"config" : {
"logical_source_type" : "match{REGEXP_MATCH(pix_type, '^6-302.*') =>
'cisco-6-302', REGEXP_MATCH(pix_type, '^5-304.*') => 'cisco-5-304', default =>
NULL}",
}
}
]
```
# `REGEX_SELECT`
```
"fieldTransformations" : [
{
"transformation" : "REGEX_SELECT"
,"input" : "pix_type"
,"output" : "logical_source_type"
,"config" : {
"cisco-6-302" : "^6-302.*",
"cisco-5-304" : "^5-304.*"
}
}
]
```
It bears mentioning that things get worse in stellar when:
1. You want to match on one of a set of regexs (e.g. `match {
REGEXP_MATCH(pix_type, 'regex1') or REGEXP_MATCH(pix_type, 'regex2') => 'foo',
...`)
2. The set of target kafka topics grows. In this example there are 2, but
if there were 5, they'd all have to fit in a long line of stellar.
I think it's not that stellar isn't equipped to handle it theoretically,
it's just that for these kinds of use-cases, it's more readable to create
something a bit more specific until we get multi-line Stellar available.
Ultimately, I consider this a stop-gap.
---
