Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storing state names in the database #211

Open
isaac opened this issue Apr 27, 2016 · 3 comments
Open

Storing state names in the database #211

isaac opened this issue Apr 27, 2016 · 3 comments

Comments

@isaac
Copy link

isaac commented Apr 27, 2016

Hi,

Statesman looks like a great gem and I would love to use it, but there is one thing holding me back: I would like to get my state names from a "states" database table. I would then like to store the primary key from the table as the value of the state in the transitions table. I would store the state names as strings (not symbols). There are a few reasons for this:

  1. If the name of a state changes I don't want to have to run a migration to change it in the database
  2. Whenever there is a transition I will send out an email - the email template will need to be in another table that references the primary key of the states table - so I need to use the relations in the database to reference states (primary keys), not just static strings or symbols

https://github.com/state-machines/state_machines - this gem enables this behaviour with the following syntax state :active, :value => 1

Would you consider implementing/supporting a change like this?

Can anyone think of another way to achieve this?

Cheers,
Isaac

@greysteil
Copy link
Contributor

greysteil commented Apr 27, 2016

Hey Isaac,

I think you could achieve this with the current setup - am I right that all you're looking for is a level of indirection on your state names? You could use constants for that:

class MyStatemachine
  include Statesman::Machine

  CREATED = :a
  SUBSEQUENT = :b

  state CREATED, initial: true
  state SUBSEQUENT

  transition from: CREATED, to: [SUBSEQUENT]

  # etc.
end

The above should give the same support as allowing you to assign a value to each state name. However, we could go further and fully integrate support for this into the gem, probably with a setting. I'm not sure exactly what that would look like, but I don't see why it would need to be breaking.

@isaac
Copy link
Author

isaac commented Apr 27, 2016

Hi Grey,

Thanks for getting back to me!

Using constants does solve one of my issues (making it easy to rename states without running a migration) but I have a few reservations about using them:

  1. I already have a states table - it would be ideal if I could use the integer primary key for this table as the state value that is stored in the transitions table. If I used constants I guess I would have to add another string column to this table to use for the constant value - I want to avoid this duplication and have everything defined in the database. In my state machine I just want to loop through all records in the states table and call MyStateMachine.state for each record.
  2. I want to use arbitrary strings as my state names - using constants imposes limitations on the characters that I can use for the name

Cheers,
Isaac

@isaacseymour
Copy link
Contributor

Hi @isaac (jealous of the username!). I think the real difficulty here is the fact that Statesman is designed to work with a static set of states, defined in the source and not changed at run-time. Do you also want to store the valid set of transitions in your database? If not, how do you define what valid transitions exist?

On your second point, I'm not sure where the constraints are imposed - the value of a constant can be anything, and Statesman supports any Ruby string/symbol for state names, so you can name your states with emojis if you wish (transition from: '😞', to: '😀' might make a more entertaining example than shopping orders!).

Isaac

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants