Support block state in $init and $validate about apama-analytics-builder-block-sdk

[gyan-sag]

I think it may be tricky to support this for partitioned models.
In partitioned models, the state is separately maintained for each partition (devices). And the correct state for correct partition is passed to the $process action when evaluating model for that partition. For $init and $validate action, it is unclear which state to pass. Calling $init and $validate action for each partition is unreasonable as number of partition may be unknown at the startup - for example receiving from all inputs.
If partition agnostic data is store in the state during the $init and $validate call, then we can probably have a separate state for passing to the $init and $validate action and then clone it to create a partition specific state when first input for a specific partition is received.

[haraldmeyer]

ok, understood. That makes sense. What about having a field in the Activation object that indicates if this is the first time $process has been called for a partition? Or is there another way to determine that?

[gyan-sag]

Adding action on Activation would not work either because the same activation object is used across all blocks when evaluating a model but you need status per-block and not per-model. Besides that, I don't think it would be too much improvement as you would still have to check if init is already done or not.

Maybe we can support $init action on the state event itself which can be called when new state object is created for a partition.

event MyBlock_$State {
  MyBlock_$Parameters $parameters;
  ...
  action $init() { // Called when new instance of this event is created
    ...
  }
}

Also, if you are computing values from parameters which does not change with inputs and across partitions, you do not need to use state object. You can directly store values in a filed on the block event itself.

[haraldmeyer]

Your last comment is spot on: my requirement can actually be fulfilled without storing the derived parameters in a state object. Did not consider this as I needed the state for other purposes anyway. I have a hard time finding other use cases at the moment, so unsure if this feature is really required.

I like your suggestion about $init but not that it would require another field $parameters that you would need to know to add by convention.