{"push_id":769985918,"size":1,"distinct_size":1,"ref":"refs/heads/raisey-bangs","head":"dcbb6fe78ccc57b8d8120706fb02131aa873cbd8","before":"65771dc39ff87529168737d7a0ec9018a687a55a","commits":[{"sha":"dcbb6fe78ccc57b8d8120706fb02131aa873cbd8","author":{"email":"0e18f44c1fec03ec4083422cb58ba6a09ac4fb2a@aprescott.com","name":"Adam Prescott"},"message":"Have setter methods raise exceptions.\n\nConsider the following flexible enum configuration.\n\n  class User < ActiveRecord::Base\n    flexible_enum :status do\n      active 1\n      inactive 2, setter: :deactivate!\n    end\n  end\n\nWhen a `User` is deactivated, it's likely that you'd see something like:\n\n  if deactivation_requested\n    current_user.deactivate!\n  end\n\nBecause of the naming of the method (with a bang) and existing Rails\nconventions, it's unlikely that you'd check the result of\n`current_user.deactivate!` to see if it was successful.\n\nMoreover, there are situations where you wish to clear out related\nrecords for all deactivations. You can currently do that by wrapping the\nsetter:\n\n  def deactivate!\n    transaction do\n      self.foos.each(&:remove!)\n      self.bars.each(&:remove!)\n\n      super\n    end\n  end\n\nAn expectation with this code is that `super` will `raise` if there are\nany problems, rolling back the transaction. Except what actually would\nhappen currently is that `super` would return `false` (through\n`update_attributes()`, no `!`), the transaction would commit, and now\nthe user is still `ACTIVE` but the `foos` and `bars` were removed.\n\nThis changes all setter methods to instead `raise` when there are\nproblems with the update.","distinct":true,"url":"https://api.github.com/repos/meyouhealth/flexible_enum/commits/dcbb6fe78ccc57b8d8120706fb02131aa873cbd8"}]}