Versioned finite-state machines with Postgres (2019)
raphael.medaer.me
Versioned finite-state machines with Postgres (2019)
1–10 of 20 posts
Re: Versioned finite-state machines with Postgres (2019)
#2[flagged]
Re: Versioned finite-state machines with Postgres (2019)
#3[flagged]
Flexibility and constraint are both useful. (Constraint is one of the reasons to use a finite state machine in the first place.) An overly constrained system can't function, an overly flexible system can't be relied upon. You'll answer your question the day you encounter a problem that NoSQL is a bad fit for, and after you learn SQL it won't feel so alien or complicated. Or maybe that day will never come and you'll never feel the need to learn SQL.
For a motivating example, consider a billing or accounting system. This domain is well known, we probably don't need the ability to rapidly evolve our schema. If we violate the constraints of this system, there may be serious consequences, like spending money we don't have or billing for the service twice.
We could build this system with either an NoSQL or a SQL database, but SQL would seem to me to be the natural choice.
Re: Versioned finite-state machines with Postgres (2019)
#4One thing I'm missing when modeling FSM like this is different states having different set of constraints, even if only being concerned with nullity. It's a shame having to make the field optional just because you do not have the appropriate value in the initial state of the entity.
Re: Versioned finite-state machines with Postgres (2019)
#5[flagged]
NoSQL will bring it's own set of issues right? Too flexible of a system with no built in Validations would mean that they need to be handled somewhere else. If we take the example in the post, refund should not precede awaiting payment, If a new status gets added, it becomes easy to know where the migrations have to be run and in NoSQL, either we write something custom or handle it each time the document is called.
Re: Versioned finite-state machines with Postgres (2019)
#6For any use-case I can think of, which are all "small data" (under 1B rows), I'd rather use DB migrations to take care of this problem rather than forcing myself to live with my previous design decisions indefinitely.
I am attracted to clever but in practice, simple always beats clever.
Re: Versioned finite-state machines with Postgres (2019)
#7[flagged]
Flexibility and constraint are both useful. (Constraint is one of the reasons to use a finite state machine in the first place.) An overly constrained system can't function, an overly flexible system can't be relied upon. You'll answer your question the day you encounter a problem that NoSQL is a bad fit for, and after you learn SQL it won't feel so alien or complicated. Or maybe that day will never come and you'll n…
I understand what you're saying, but in the example for accounting, we can also solve this problem using NoSQL. Because the most important feature we're talking about there is transaction support. Similarly, schema-on-write can be provided by a library.
To me it seems like NoSQL works better when there is less to normalize, which is the case with microservices. Those services struggle with the support for a distributed transaction when they have to make a distributed transaction. This problem will be very easily solved in SQL (assuming its not shared to completely denormalize everything for performance).
Note that this normalization problem also shows up in schema-on-write. If multiple people are contributing to a schema from different teams, then it will become hard to maintain a schema-on-write.
Re: Versioned finite-state machines with Postgres (2019)
#8[flagged]
NoSQL will bring it's own set of issues right? Too flexible of a system with no built in Validations would mean that they need to be handled somewhere else. If we take the example in the post, refund should not precede awaiting payment, If a new status gets added, it becomes easy to know where the migrations have to be run and in NoSQL, either we write something custom or handle it each time the document is called.
Surely that logic should not sit in persistance layer though?
Re: Versioned finite-state machines with Postgres (2019)
#9For any use-case I can think of, which are all "small data" (under 1B rows), I'd rather use DB migrations to take care of this problem rather than forcing myself to live with my previous design decisions indefinitely. I am attracted to clever but in practice, simple always beats clever.
Wouldn't that risk some FSM getting modified while it's 'running'? That may or may not be desirable I guess. Eg. a customer not knowing that the process changed since they placed an order and not understanding the process anymore
Re: Versioned finite-state machines with Postgres (2019)
#10[flagged]
[deleted]