Skip to content
This repository has been archived by the owner on Aug 11, 2023. It is now read-only.

Refactor backend state store #319

Open
ethanjli opened this issue Apr 19, 2021 · 1 comment
Open

Refactor backend state store #319

ethanjli opened this issue Apr 19, 2021 · 1 comment
Assignees
Labels
domain: backend On the backend stage: dev On/for a development version type: feature Brand new functionality, features, pages, workflows, endpoints, etc. type: fix Iterations on existing features or infrastructure work: obvious The situation is simple/obvious/clear, best practices used
Milestone

Comments

@ethanjli
Copy link
Contributor

ethanjli commented Apr 19, 2021

Currently the backend's state store is a dict associating protobuf message types as keys to protobuf message instances as values. This leads to an awkward type system (as accessing state segments in the store requires a typecast). We should instead make the backend state store more like the firmware state store, where state segment objects are statically typed, but still are accessed by indexing on a value (either a protobuf message type, or as will be done in #313, a StateSegment enum; this might also require moving state input from the StateSynchronizer protocol into the Backend protocol, like what we do in the firmware).

One option might be to define a Store class (or dataclass) with members, and to define a custom way of accessing members by passing in an enum.

@ethanjli ethanjli added domain: backend On the backend stage: dev On/for a development version type: feature Brand new functionality, features, pages, workflows, endpoints, etc. type: fix Iterations on existing features or infrastructure work: obvious The situation is simple/obvious/clear, best practices used labels Apr 19, 2021
@ethanjli ethanjli self-assigned this Apr 19, 2021
@ethanjli ethanjli added this to the v0.7 milestone Apr 21, 2021
@ethanjli ethanjli linked a pull request May 5, 2021 that will close this issue
@ethanjli
Copy link
Contributor Author

ethanjli commented May 5, 2021

A first pass of refactoring was done in #313, but it only partially addresses this issue. Now we have a StateSegment enum, and we're accessing segments in all_states using it, but we still have an awkward type system where we have to cast every state segment we access. We should add strong typing to the store, as described above.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
domain: backend On the backend stage: dev On/for a development version type: feature Brand new functionality, features, pages, workflows, endpoints, etc. type: fix Iterations on existing features or infrastructure work: obvious The situation is simple/obvious/clear, best practices used
Projects
None yet
Development

No branches or pull requests

1 participant