I implemented this again today, and realized it was a pattern that I fall back on regularly.
When dealing with a system with several states, and actions to be performed at each state, I usually break things up into a state diagram. Inevitably, I end up with a “State” field, the the question becomes what to put in the state field.
Take an example of sending an invite to a user to come in and use an app.
What I do not do:
Alter Table Invitation
add state int not null default(1)
enum State { Start = 1, Email = 2, Consumed=3, Expired=4 }
What I do (approximately):
alter table Invitation add
state varchar(25) null,
stateError bit(1) default(0) null,
stateTimestamp DateTime default(getdate()) not null
public static class InvitationState {
public const string SendEmail="SendEmail";
public const string WaitInbound="WaitInbound";
public const string InviteConsumed="InviteConsumed";
public const string InviteExpired="InviteExpired";
}
Why?
- It is my experience that for any flow, a future spec will come up with will add new states in the middle of that flow. If you go with an int value, you end up with the flow being 1->9->5->6. By going with a varchar, its much more obvious when doing a select from the db, and it allows for the addition of new states.
- A previous employer loved using CHAR(4) and state names like “STRT”,”MAIL”,”CONS”,”EXPR” because Oracle stored the Char(4) like an int. Very similar to Apple’s Resource Fork’s from back in the day.
- I’m not so worried about the speed difference it makes. I feel that the flexibility it gives makes up for any performance loss.
- Either we have an action state, named with a “Verb Noun”, or we have and end state, named with “Noun Verb”.
- The state names are based on what IS happening or SHOULD happen to the row, not what has already happened, except for the end states.
- For any action state, if the attempt at performing that action fails, I set the stateError bit to 1. This lets me know I need to do something to fix that; when its fixed, I can change the stateError back to 0.
- In large batch systems, I write the console based action-taker with an override switch: to work on a specific Id, even if the errorState=1; and to do it in a transaction but not commit the transaction.
- This lets me do test-things with rows that failed, while the main batch system processes all the other non-errored rows. Once I get it to working, I tell it to go ahead and commit, and the system continues on its merry way.
- The system only deals with the states that it knows. This lets the technical OPS team (whoever that is) use the state field for its out-of band processes, stuff like setting the state to ‘Ken’, for example. Because Ken is the man who knows what is up with those rows.
- In really large critical systems, there’s an audit table and a trigger that auto-inserts any changes to the audit table.
The result of this is, I get Christmas cards in the mail from former clients with phrases like “Still amazed by your code!!!”. 🙂
Hope this helps.
