elguardian commented on issue #1181:
URL:
https://github.com/apache/incubator-kie-issues/issues/1181#issuecomment-2228026315
@fjtirado Let me throw something into the table.
I am ok with the suggested database persistence tier, that should be enough.
So I would say something like this. As for the impl we are using variables for
this, I would suggest to say something like
For the variable (in the process definition)
Variable
a. Variable Persistence Strategy (at least two impl). In this case we should
add to the strategy the state of the variable to avoid loading the variable
several times like not loaded, dirty, in sync... something like that.
1. In process state variable (current strategy): in this case the state
of the variable is always in sync.
2. database persistence strategy. in this case depends how it is readed.
b. state of the variable just façade against hte variable persistence
strategy.
VariablePersistenceStrategy should contain the name and the context id (TBD
later) as variable name can be duplicated among subcontext. I am ok with the
tree columns if the value column contains at least the type; otherwise we need
to include that
We can reuse the
https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/jbpm/process-serialization-protobuf/src/main/java/org/jbpm/flow/serialization/impl/ProtobufVariableReader.java
https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/jbpm/process-serialization-protobuf/src/main/java/org/jbpm/flow/serialization/impl/ProtobufVariableWriter.java
for persistence strategy depending of the variable type.
Regarding how to specify what type of strategy. that is up to the parser. So
in case of sonataflow should setup The variable process definition in the right
approach, in the same way for BPMN or CMMN case entries.
That would be the general idea from my side
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
