MQTTSink topic parameter, unable to use attribute as topic

[chanskw]

Since we have moved to implement MQTT operators in Java, the MQTTSink operator can no longer take the topic from an attribute of the data stream. Creating this issue to track the problem and we need to figure out how to lift this limitation.

[chanskw]

@ddebrunner I need a work-around for this in Streams 3.2. Historically, how do people normally get around this limitation when implementing Java operators?

The MQTTSink operator can be invoked like this:

() as MQTTSink_6 = MQTTSink(Format_11_out0 as inPort0Alias)
{
param
serverURI : $serverUri ;
topic : "topic1" ;
}

I am thinking if we invoke the operator like this:
() as MQTTSink_6 = MQTTSink(Format_11_out0 as inPort0Alias)
{
param
serverURI : $serverUri ;
topic : "$attributeName" ;
}

The $ prefix signifies that the topic will come from an attribute from the incoming stream, and the operator will figure out what the topic value should be. If there is no $ prefix, we will publish with the topic provided as is.

I realize that this is a work-around and we can probably do something more "standard" in the future. I am trying to get the operators to work for 3.2 and therefore need to find a solution for that.

Thanks!

[ddebrunner]

Why not just a parameter called topicAttributeName that is an rstring containing the name of the attribute?

[ddebrunner]

The operator can support parameters topic and topicAttributeName and have them mutually exclusive.

[chanskw]

I just did not want to introduce another parameter that sort of serves the purpose of the topic parameter. I think having two parameters with mutually exclusive rule is more complicated. It just seemed that supporting a "variable" in the topic parameter is simpler.

In the future, if we do support allowing attributes in parameter for Java operator, the code changes required to migrate is smaller. Once a parameter is introduced, it becomes an API. I do not want to have to support this extra parameter when we support attributes in parameter in the future.

[ddebrunner]

The $ approach also becomes part of the api, and seems more confusing to me. What happens if the topic itself starts with a $, will an escape sequence need to be introduced?

Other java operators have used the name of the attribute approach, not sure why a different approach needs to be introduced for this operator.

[chanskw]

Just trying to simplify things, so we have a single parameter.
Since other operators take the extra attribute approach.. will follow that approach.

[chanskw]

Fixed, added parameter: topicAttrName, added compile time checks, made topic parameter optional