Persistence on python-state-machine: some remarks

[brunolnetto]

I believe this is an appropriate place to propose ideas around database persistence for the python-statemachine library. If you're not interested in persisting state-machine transitions to a database—or consider it overkill—feel free to skip the rest. The thoughts below align with the current version of the library, which is based on the Event object rather than Transition.

Use Case

I was tasked with refactoring a queue-based structured file importer. The legacy code implemented a database-based model to store states such as queued, failed, and succeeded. While exploring solutions, your library came to mind—it was a "what if" eureka moment, even though the original codebase is in C#.

Proposal

Similar to the optional dependency pydot, integrating libraries like SQLModel could provide an out-of-the-box entity-relationship model for those interested in persisting not just transitions but also modifications to their state machines. This approach would introduce some overhead, as it would require modification tracking for versioning, akin to how the library alembic handles schema migrations.

With deeper expertise, contributors could design suitable fact and dimension tables, along with relevant measures, to support this functionality.

Inspiration from FlowBuild

Handling state-machine instance history and versioning resembles the approach of another JavaScript library I worked with at FDTE: FlowBuild. Despite language differences, FlowBuild's core models—workflow, process, and process_state—parallel potential entities in this context:

• statemachine: Represents the state machine itself, including its definition and metadata.
• sm_instance: Denotes an instance of the state machine, capturing its current state and context.
• sm_step: Records each transition or step, including timestamps for entering and exiting states.

Conclusion

This proposal serves as "brain-food" rather than a rigid plan, aiming to spark ideas. With structured state machines gaining popularity, especially in queue-based or distributed systems, having a robust persistence strategy could elevate python-statemachine to a first-class citizen in production environments.

I'm happy to discuss or help design something more concrete if this direction is of interest.