If you build a state machine on top of a relational database you can abstract concurrency problems away from your business logic and allow developers to write safe-by-default code without dealing with concurrency concerns. This post explains how to build a library that offers those protections, and how they work under-the-hood.
I don’t understand why the most_recent field is needed. Surely the most recent state can be derived from the order field and the unique constraint on it can prevent concurrency issues if the previous sequence is taken before the state change. The benefit would be that the transition history table could then be append only.
Yeah, I’m wondering that too. Also, why would a transition ever be updated? Should a successful transition not be a write-once operation?
I guess it boils down to the finer details of the requirements of the application.
I think the most_recent is to power the unique index constraint. This “powers” the whole thing.
Whereas the sort_order is to allow easy sorting, which is just for human readability. You could argue that you can rely on the “created_at” for this.
Considering the examples increment it by 10, I assume this is to allow admins to manually override a sequence or force a data consistency thing or whatever.
I think the most_recent is to power the unique index constraint. This “powers” the whole thing.
That much is clear, the question is: why is it needed at all? The sort key has the same uniqueness constraint, so there cannot be two entries with the same sort key value. So under which circumstances does the highest sort key value not reject the most_recent transaction?
I guess separation of concerns? One is for the system, one is for display?
A unique Boolean is easier to query than sorting and limiting?
Maybe you don’t ever need the ability to display a history, but you still want the history (instead of just making the transaction_id unique constrained)… so you just drop the sort_order column?
I understand what you are saying.
Maybe that’s just how they went about it. Originally planning on using created_at to do the ordering, then later realising that a customisable sort_order is required so they can make things make sense without having to fudge timestamps.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
I don’t understand why the
most_recentfield is needed. Surely the most recent state can be derived from the order field and the unique constraint on it can prevent concurrency issues if the previous sequence is taken before the state change. The benefit would be that the transition history table could then be append only.Yeah, I’m wondering that too. Also, why would a transition ever be updated? Should a successful transition not be a write-once operation? I guess it boils down to the finer details of the requirements of the application.
I think the most_recent is to power the unique index constraint. This “powers” the whole thing.
Whereas the sort_order is to allow easy sorting, which is just for human readability. You could argue that you can rely on the “created_at” for this.
Considering the examples increment it by 10, I assume this is to allow admins to manually override a sequence or force a data consistency thing or whatever.
That much is clear, the question is: why is it needed at all? The sort key has the same uniqueness constraint, so there cannot be two entries with the same sort key value. So under which circumstances does the highest sort key value not reject the most_recent transaction?
I guess separation of concerns? One is for the system, one is for display?
A unique Boolean is easier to query than sorting and limiting?
Maybe you don’t ever need the ability to display a history, but you still want the history (instead of just making the transaction_id unique constrained)… so you just drop the sort_order column?
I understand what you are saying.
Maybe that’s just how they went about it. Originally planning on using created_at to do the ordering, then later realising that a customisable sort_order is required so they can make things make sense without having to fudge timestamps.