Make `status` column to be `integer` and be backed by `enum/state_machine`
Problem to solve
Today, we create a lot of tables that have state/status
.
This status is an internal representation of a moment in which the given object is.
Proposal
For improving the readability and performance of such representations, this proposes to:
- always use
integer
of appropriate size - always use
state_machine
if an object is astateful
- always use
enum
if an object is astateless
(stateless in a sense that object just holds a state, but does not implement state transition, example would be mirroring someone else state)
Having a consistent representation allows us:
- consume less space due to more efficient storage (integer vs string, indexing of a string column)
- have built-in helper methods that allows to access different states
- have a method to validate the completeness of implementation for codepaths that use the given state, by having a consistent way of accessing all possible states
- have an effectively strong validation of what is stored in a table, as only some "names" are translatable to meaningful values (non-nil ones)
We could achieve that by:
- checking that each column that is
state/status/_state/_status
is of typeinteger
, - checking that each such column is backed by either
state_machine
orenum
Over time we should update all existing tables that still use string
to integer
where possible
Check-list
-
Make sure this MR enables a static analysis check rule for new usage but ignores current offenses -
Mention this proposal in the relevant Slack channels (e.g. #development
,#backend
,#frontend
) -
If there is a choice to make between two potential styles, set up an emoji vote in the MR: - CHOICE_A:
🅰 - CHOICE_B:
🅱 - Vote yourself for both choices so that people know these are the choices
- CHOICE_A:
-
The MR doesn't have significant objections, and is getting a majority of 👍 vs👎 (remember that we don't need to reach a consensus) -
(If applicable) One style is getting a majority of vote (compared to the other choice) -
(If applicable) Update the MR with the chosen style -
Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK -
Follow the review process as usual -
Once approved and merged by a maintainer, mention it again: -
In the relevant Slack channels (e.g. #development
,#backend
,#frontend
) -
(Optional depending on the impact of the change) In the Engineering Week in Review
-
Edited by Kamil Trzciński