[Interest] serialization of QStateMachine for recovery mode

[Mandeep Sandhu]

>
> Well, in general I would consider working with this approach and automatically adding those transitions between the start state and all other states. QTransition could be derived to QRecoveryTransition that throws only if a QRecoveryEvent is posted.
> But then we would need to keep some kind of a reference to the current state within the state machine. And I saw no opportunity to address the current state in QSM. Automatically adding a unique ID might help here...


QSM has an API QStateMachine::configuration(). This doesn't exactly
give you the lowest level state the SM is currently in but ALL the
states (lowest + all it's parent states). I had similar requirement
where I wanted to know the lowest level child state the SM is in. So I
wrote a small "state tracker" so to speak, which had a "state"
property which was changed by the Qt SM using its property assignment
features.

>
>
> But as my intention is to use this approach in a work flow driven application that takes care of building up a set of data I also will have to take care of keeping data and state machine consistent.
> If some data would be lost but the state machine is recovered to a later state then we would end up in an inconsistent state! So recovering any state without check of data is critical.
>
> So my current approach is to recover the data and set up a special QRecoveryState/-Transition connection with guards on data elements that once an QRecoveryEvent is posted automatically goes all the way to the right state.
>
> Would that be a considerable approach?


You can also look at having a different initial state
(QAbstractState::setInitialState())  based on if the app started
normally or in recovery mode, but then you'd loose any history that
you might've had (if using history states in the SM).

HTH,
-mandeep

>
>
> Great discussion!
>
> Best Regards,
> Ingmar
>