python-statemachine
python-statemachine copied to clipboard
Documentation suggestion: parallel states
Thanks for building this repo! I'm not 100% sure my use case is possible based on the documentation - if it is I'd love to add some documentation for it!
Let's say I have a state like the following for writing a plan:
- Plan is written
- Plan submitted for approval from inspectors 3a. Plan is approved by Inspector 1 3b. Plan is approved by inspector 2
- Plan is approved
Steps 3a and 3b are run in parallel - either inspector could approve the plan first. And step 4 is only achieved once both 3a and 3b have been achieved.
Is there an easy way to handle a "parallel state" like this (3a and 3b)? Thanks for any advice or help, and thanks for building this!
The parallel edges you describe may be additional properties rather than states. The inspector are ACTORS which alter the document STATE. From my perspective, every document has the following states: and state transitions:
OnDebt, Ongoing, UnderApproval, Approved
OnDebt -> Ongoing Ongoing -> OnDebt Ongoing -> UnderApproval UnderApproval -> OnDebt UnderApproval -> Ongoing UnderApproval -> Approved
The following state machine helps you with your example:
http://codepad.org/s5PZVL0b
@YPCrumble thanks for your question. Currently there's no built-in support for parallel states as described by scxml.
I think that supporting this will be a nice improvement. That being said, I think that will require breaking changes to the API.
I'm starting to think about this and compound states, let me know if you wanna help. What do you think that the solution should looks like? How a parallel state should be expressed in code?
@fgmacedo thanks for your update! I ended up going with flags on my model and rolling my own state machine but it wasn't an ideal solution. I'm not 100% sure how I would implement - the fact that two parallel processes can happen at separate times makes it difficult to imagine implementing without storing whether the first of the parallel processes has happened already somewhere...that's where I got stuck.
I play the role of GitHub-bot to say this issue stalled for so long (since Mar 16 2021). It is highly recommended, not to say preemptive, to close this issue if no further issues are related to it.
It's old but still worth it.
Please don't play this role of "Github-bot" @brunolnetto. It's not needed as the number of issues is relatively small.
Great. May we move stalled issues to "projects" tab, yes?
Closing as it's not a documentation issue. We need to add support for composed/parallel states to achieve this.