Switch Operator Processors

[heisenbergs-uncertainty]

Purpose

Introduce Pipeline Element Processors that allow a user to implement the "Switch" operator. I have often found myself wanting to setup a pipeline that uses the "Switch" operator but have had to use a complicated set of boolean conditions to try and implement it or I eventually end up just using a JavaScript processor to use the switch statement. The processors reflect the following block.

switch(String x) {
  case "test":
   do something;
   break;
  case "test 2":
   do something else;
   break;
  default:
   do this if nothing else works;
   break;
}

The proposed updates introduce three processors, each which have the purpose of handling a different input type. I have implemented a Boolean Input processor, String input processor, and Numerical input processor. This is done primarily for the sake of cleaner code along with simplifying the detection of the incoming event property. These three processors could be combined into one "Switch Operator Processor" if there was the introduction of some "Conditional Requirements" component.

Remarks

I have written unit tests for the numerical processor locally but ran into issues when I transferred the updates from my custom extensions repo to the main streampipes codebase. If someone has input on the right way to write tests for streampipes or would like to write the unit tests themselves that would be welcome.

PR introduces (a) breaking change(s): no
PR introduces (a) deprecation(s): no

[tenthe]

Hi @heisenbergs-uncertainty,

Thanks a lot for the PR — these are great new processing elements, and your description makes it easy to review.

• For unit tests, you can use the ProcessingElementTestExecutor helper class.

• See TransformToBooleanProcessorTest or NumericalFilterProcessorTest for examples.

Would you like to add some unit tests for your elements?
Feel free to reach out if you have any questions or suggestions for improving the test framework.

Hope this helps!

[heisenbergs-uncertainty]

Hi @heisenbergs-uncertainty,

Thanks a lot for the PR — these are great new processing elements, and your description makes it easy to review.

• For unit tests, you can use the ProcessingElementTestExecutor helper class.
• See TransformToBooleanProcessorTest or NumericalFilterProcessorTest for examples.

Would you like to add some unit tests for your elements? Feel free to reach out if you have any questions or suggestions for improving the test framework.

Hope this helps!

Hey @tenthe! Thank you for the testing recommendation, that was super useful and made writing the tests much simpler. Props to whoever wrote that suite!

I have gone ahead and added unit tests for the processors and made quite a few updates that they helped me catch. From my testing it should be good to go at this point.

[tenthe]

Hi, thanks for the changes.
I just had a minor comment, but I think the code looks good from my side.

I look forward to use the processors.
Cheers,
Philipp

[tenthe]

Can this be an abstract method?

[heisenbergs-uncertainty]

I don't think so. Switching it to abstract is causing the classes that extend it to refuse to implement the class.

But I am still refreshing my understanding of Java so I will default to your decision.

[tenthe]

Thanks for your response. This was just a small point I noticed while reviewing the code. I'll trigger the GitHub Action validation now. Once it passes, we can proceed with merging your PR.