state_machines VS time_for_a_boolean

State Machines (Ruby) - A popular library providing a Ruby DSL for easily building finite state machines

As a regular user of the state_machine Ruby gem, I wouldn't recommend it. If you don't believe me, just check out the "Class definition" section of the usage examples: https://github.com/state-machines/state_machines#usage

The problems are obvious. It's built on magic and indirection. This leads to difficult to debug state machine problems. For anything beyond simple state machines you quickly lose any idea of what your object is doing.

Might this be better handled with a state machine with active record integration?

Here's an example of how it can happen - look at the code examples in https://github.com/state-machines/state_machines - almost everything you are coding is in the DSL of that library if you are using it:

There's a gem that handles this behavior. I haven't personally used it, but I heard about it on the Bikeshed podcast. time_for_a_boolean

There's a gem for treating timestamp columns like booleans https://github.com/calebhearth/time_for_a_boolean. I haven't personally used it, but it seems to be a similar solution to what some people here have suggested

It might not be the most efficient if your app scales to millions of messages, but perhaps adding another table with a schema like `message_id`, `user_id`, `read_at`. Don't forget to eager load this new relation, as it can lead to N+1 errors.On the app that I work on, we use the gem time_for_a_boolean which allows us to treat a nullable timestamp field. It might be useful for your project too.