State transitions do not persist to DB in ActiveRecord models

[jaryl]

foo.bar! does not persist to the database due to a failed validation. The documentation for the WriteState::aasm_write_state method indicates that update_attribute is being used to bypass validation, but this is not the case.

After calling write_attribute, save is being called to persist the changes. Since save does validation, this breaks the design of state transitions in AASM.

A proposed fix would be to call save(false) to skip validation, see pastie:

http://www.pastie.org/444480

[billstickers]

just got bitten by this bug myself.

[jaryl]

Yeah, and you'd think that more people would be experiencing this. There are 556 watchers.

[jaryl]

I forked the repo and fixed the error @ http://github.com/Jaryl/aasm/tree/master. Now, how does this thing work, should I leave it at this or do I submit a pull request or what?

[lwu]

Note that the newest documentation (or at least the source as of version 2.1.5) now just says "Writes state to the state column and persists it to the database", which means that your state will not be persisted unless the object validates.

[jaryl]

Iwu, you are right. You may want to follow the discussion here:
http://rubyist.lighthouseapp.com/projects/13207/tickets/18-state-transitions-do-not-persist-to-db-in-activerecord-models

[halorgium]

My belief is that if the model is in a state which is currently invalid, the transition should fail if only to prevent further invalidation.
Even if the state transition would make the model valid, the potential of having an invalid model persisted only creates more confusion.

Perhaps a solution would be to check if the model is valid before attempting transitions.

[jaryl]

I'm currently using state_machine in my projects, which provides facility to validate/invalidate state changes, in case any of you are shopping around.

[alto]

So, what do you expect to happen? Returning false if trying to change the state of an invalid object? Or do you prefer to throw an exception?

[halorgium]

I would expect that a state change would either raise an exception or return false.
Just like in AR::Base#update_attributes! vs. AR::Base#update_attributes.

The main thing is that the transition did not occur.

[alto]

Okay, I see. If the state is not changed, then it's a bug, and I'll fix it soon.

[alto]

I just released version 3.0.2, where I added a switch to the aasm configuration (:skip_validation_on_save) to make sure that states are stored to the database even if the model is invalid. Look at the readme on https://github.com/rubyist/aasm, section 'Persistence example' how to apply it.