troessner / transitions Goto Github PK

Hi, I'm getting this error when trying to fire an event:

NoMethodError: undefined method `call_action' for nil:NilClass
    from /Users/jmonegro/.rvm/gems/ruby-1.9.3-p194/gems/transitions-0.1.0/lib/transitions/machine.rb:47:in `fire_event'
    from /Users/jmonegro/.rvm/gems/ruby-1.9.3-p194/gems/transitions-0.1.0/lib/transitions/event.rb:31:in `block in initialize'
    from (irb):1
    from /Users/jmonegro/.rvm/gems/ruby-1.9.3-p194/gems/railties-3.2.7/lib/rails/commands/console.rb:47:in `start'
    from /Users/jmonegro/.rvm/gems/ruby-1.9.3-p194/gems/railties-3.2.7/lib/rails/commands/console.rb:8:in `start'
    from /Users/jmonegro/.rvm/gems/ruby-1.9.3-p194/gems/railties-3.2.7/lib/rails/commands.rb:41:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

Here's my code:

  class Order < ActiveRecord::Base
    include ActiveModel::Transitions

    state_machine do

      state "Order Received"
      state "Order Shipped"

      event :ship, success: :notify_customer do
        transitions :to => "Order Shipped", :from => "Order Received"
      end

    end

    private

    def notify_customer
      true
    end

  end

And trying to do order.ship!

Any pointers?

Thanks!

With AASM, I was using @foo.aasm_events_for_current_state and @foo.aasm_events_for_state(the_state) to verify whether a specific event could be called before actually calling it. This was necessary as a validation because I have an attr_accessible :event which is used in forms (select field) to change state.

With Transitions, I tried using self.class.state_machines[:default].events_for(self.state.to_sym) instead of events_for_current_state, and it works and contains the event I want to call. However, when I subsequently call the event using self.send("#{self.event}"), I get a InvalidTransition exception.

I noticed that Transitions does not normalize state names to "string" or :symbol form, i.e. when I set the state using strings, but compare it using symbols, or vice versa, comparison fails.

Is this a known bug? Or else, how would I solve this task using Transitions?

Thanks!

Here is the reasoning:

1.) If you really need multiple state machines for one model, you probably need multiple models.
So far, I have not seen a valid use case for multiple state machines, which was not better expressed
by using multiple models.

2.) The current transitions semantics and API is not suited for multiple state machines:
Right now events are just plain methods defined on the models itself.
Consider you had multiple state machines, on named day and one named night, both with differing events.
What to do when you switch to state machine day but trigger an event defined on night?
You can either allow it, but this would make multiple state machines pointless if there is no enforced
separation of concerns. Or you disallow it, in which case events would either have to be bound
to state machines, not to the object itself, which would be tedious and ugly, or the events themselves
would need to check if they are allowed to be called. The last solution seems like a clean solution
but it would require a decent amount of rewriting existing code - and I just do not see the benefit for this.

3.) Kind of a weak point, but right now the functionality is broken anyway throughout the gem. This functionality
is not even documented, so the side effects on existing projects should be minimal.

On the plus side, removing the possibility of having multiple state machines will streamline and improve existing
code a lot.

When selecting aggregates with custom SQL the error is raised.
It worked perfectly in 0.1.4 but broke in 0.1.5

Game.select("DISTINCT(games.version)")

results in "missing attribute: state". By changing

Game.select("DISTINCT(games.version), state")

it works. So it appears it's not possible to pull the transitions model without including the state column.

I've been using transitions on a rails project since the 0.1.5 version and everything has been running good. However, I needed to go beyond 0.1.6 to access the multiple success callbacks.

When first moving transitions into my model, the column name for the state was already set as status. 0.1.6 was not around yet so I ended up using the following piece of code to alias the column name and still tap into the transitions gem.

alias_attribute :state, :status    #This alias is needed for the state_machine 

However, something as simple as the following state machine appeared to be failing on updating the 'state' of the object. I was hitting the success callbacks fine but the state was not progressing.

state_machine :initial => :pending do 
  state :pending
  state :queued

  event :enqueue_object, :success => :do_something_else do
    transitions :to => :queued, :from => [:pending] 
  end
end

def do_something_else
  #state would actually report :queued here
end

So overall this would be the overall path

temp = SomeModel.new
#state starts out as :pending
temp.enqueue_object!     #The success callback will report the current_state being :queued
#state will still show :pending

However, I was able to fix this by using the new column names when initializing the state_machine (thankfully). However, I don't know how this should function in the scenario that I described. My impression that it would/should still work. I tested this out on a simple Ruby class and everything seemed to work.

This appears to be the potential change set that may have impacted this:
1304a15

I toyed around with the code a bit but I am pretty unfamiliar with it and was unable to get it "corrected" right away. I also did not know if it was a correction that was worth putting in.

Regardless, just let me know if you need any extra information. This is my first time really ever bringing something up on a public project and hopefully I've provided enough information! Thanks again for the gem!

See http://github.com/qoobaa/transitions/issues/closed#issue/3/comment/319647 for more details. Fork at: http://github.com/tekin/transitions fixes this issue.

I'm using Ruby 1.9.3 and Rails 3.2.6 - I've not tried this on any other version, so I'm not sure if this is a ruby bug or something else.

I wanted to clean up my code, as the model I'm using this with has 500+ lines of code. And that drives me nuts. I put the methods called on transition into a concern, and when I try to change states, I get the following message:

SystemStackError: stack level too deep
    from /Users/doug/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/irb/workspace.rb:80
Maybe IRB bug!

Again, not sure if this is related to ruby, rails, or this gem, but I figured I'd at least let you know.

Concrete use case:

Admin interface: List all possible state names an object can have.

Right now this is only possible like this:

Order.state_machines.first[1].states.map(&:name)

which is obscure and counter intuitive.

We need something which is intuitive and easily accessible a la:

Order.possible_states

which the first state machine being the default argument or something like that.

I'll look into this as soon as possible.

When you load up a class it, as part of the transitions methods, loads an instance of the class to see if it responds to a given method.
It then throws a grumpy error if that method's already taken.

Here's the thing, though.
This is making an instance of the class inside the class's definition.

This means that it only sees methods which are defined before state_machine.
Methods after that block in the class aren't loaded by the time it runs, and aren't detected by that check.

The actual issue we saw this in, though, was that we had a method that set a value in a model if there wasn't already one.
We decided to put that in an after_initialize Rails callback to run whenever we make a new value to ensure a sane default.

Then, when doing anything with the class, including calling a class method, it would explode because it thought that method wasn't defined.
This confused us for a long time before we found that when we defined the state_machine it was making an instance of this class, which fired the after_initialize handler, which tried to call a method which wasn't loaded by the time state_machine was run.

I don't know if there's a good way to work around this... but I'm also not quite sure how valuable the check is.
Some of the methods it generates it checks beforehand in this way, but other methods it just dumps on top of whatever used to be there.
Thoughts?

In my AR.

class Item < ActiveRecord::Base

  include ActiveRecord::Transitions
  state_machine do
    state :submitted
    state :available

    event :make_available do
      transitions :to => :available, :from => :submitted
    end
  end
end

Keep getting error like below
> i = Item.find(1)
=> #<Item id: 1, name: nil, descriptio: nil, collectio_id: nil, created_at: "2011-01-15 20:58:12", updated_at: "2011-01-15 20:58:12">
> i.state
NoMethodError: undefined method state' for #<Item:0x000001040c5a80> from /Users/ovsiiko/.rvm/gems/ruby-1.9.2-p136/gems/activemodel-3.0.3/lib/active_model/attribute_methods.rb:364:inmethod_missing'
from /Users/ovsiiko/.rvm/gems/ruby-1.9.2-p136/gems/activerecord-3.0.3/lib/active_record/attribute_methods.rb:46:in method_missing' from /Users/ovsiiko/.rvm/gems/ruby-1.9.2-p136/gems/activerecord-3.0.3/lib/active_record/attribute_methods.rb:44:inmethod_missing'
from (irb):3
from /Users/ovsiiko/.rvm/gems/ruby-1.9.2-p136/gems/railties-3.0.3/lib/rails/commands/console.rb:44:in start' from /Users/ovsiiko/.rvm/gems/ruby-1.9.2-p136/gems/railties-3.0.3/lib/rails/commands/console.rb:8:instart'
from /Users/ovsiiko/.rvm/gems/ruby-1.9.2-p136/gems/railties-3.0.3/lib/rails/commands.rb:23:in <top (required)>' from script/rails:6:inrequire'
from script/rails:6:in `

Can't get what's wrong... RVM bug? Any help appreciated. Thanks

It would be handy if this behaviour was supported by default

@user = User.active.first 
@user.retired_at => nil
@user.retire!
@user.state => "retired"
@user.retired_at => Time.now

Thanks

Version 1.8 doesn't support Symbol#empty? as 1.8 doesn't support :"" as a symbol name.

NoMethodError: undefined method `empty?' for :pending:Symbol
from ..snipped../bundle/ruby/1.8/gems/transitions-0.1.2/lib/transitions.rb:82:in `current_state'

I suppose the easiest fix would be including some code like

begin
  :symbol.empty?
rescue NoMethodError
  class Symbol
    def empty?
      to_s.empty?
    end
  end
end

alternatively if you were to only include the code for Ruby 1.8 then this would suffice as an empty symbol is not possible in 1.8

class Symbol
  def empty?
    false
  end
end

Hi,

When setting up a model's transition/state machine, is there a convenient way to specify a method to be called on every state transition? (For instance, a record method that constructs/logs a timeline of state changes)

Thanks,
cork.marshall

authorized:
  description: authorized order
  amount: 100
  state: authorized #note, this is not read correctly by the transitions gem

when instantiated in a test, the state attribute of the ActiveRecord object will not match the result of calling current_state on the same object (assuming the default state isn't :authorized).

I have a problem when trying to delete a entry with user.destroy when using state frozen
Transitions::InvalidTransition: Cannot transition to default from frozen for User

Can be reproduced with:

rails new transitions_test -d sqlite3

Add gem 'transitions', :require => ['transitions', 'active_record/transitions'] to Gemfile

bundle install
rails g model User state:string
rake db:migrate

Adapt app/models/user.rb

class User < ActiveRecord::Base
  include ActiveRecord::Transitions
  state_machine do
    state :new
    state :frozen

    event :freeze do
      transitions :to => :frozen,:from=>:new
    end
  end

end

Start Rails console:

1.9.3p125 :001 > u = User.create
   (0.1ms)  begin transaction
  SQL (32.4ms)  INSERT INTO "users" ("created_at", "state", "updated_at") VALUES (?, ?, ?)  [["created_at", Wed, 21 Nov 2012 10:40:08 UTC +00:00], ["state", "new"], ["updated_at", Wed, 21 Nov 2012 10:40:08 UTC +00:00]]
   (3.5ms)  commit transaction
 => #<User id: 3, state: "new", created_at: "2012-11-21 10:40:08", updated_at: "2012-11-21 10:40:08">
1.9.3p125 :002 > u.freeze!
   (0.1ms)  begin transaction
   (4.5ms)  UPDATE "users" SET "state" = 'frozen', "updated_at" = '2012-11-21 10:40:13.126501' WHERE "users"."id" = 3
   (3.8ms)  commit transaction
 => true
1.9.3p125 :003 > u.destroy
   (0.1ms)  begin transaction
  SQL (40.2ms)  DELETE FROM "users" WHERE "users"."id" = ?  [["id", 3]]
   (24.0ms)  rollback transaction
Transitions::InvalidTransition: Cannot transition to default from frozen for `User`

NoMethodError: undefined method to_sym' for nil:NilClass /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/transitions-0.1.9/lib/active_model/transitions.rb:91:inset_initial_state'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.1.12/lib/active_support/callbacks.rb:395:in _run_initialize_callbacks' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.1.12/lib/active_support/callbacks.rb:81:inrun_callbacks'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/base.rb:1622:in init_with' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/base.rb:959:ininstantiate'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/base.rb:470:in block in find_by_sql' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/base.rb:470:incollect!'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/base.rb:470:in find_by_sql' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:115:inblock in to_a'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/identity_map.rb:72:in without' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:114:into_a'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:17:in rescue in collect' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:15:incollect'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:257:in construct_limited_ids_condition' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:242:inapply_join_dependency'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:231:in construct_relation_for_association_find' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation/finder_methods.rb:210:infind_with_associations'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:115:in block in to_a' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/identity_map.rb:72:inwithout'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:114:in to_a' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:130:into_a'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activerecord-3.1.12/lib/active_record/relation.rb:432:in ==' /home/travis/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/test/unit/assertions.rb:187:in=='
/home/travis/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/test/unit/assertions.rb:187:in assert_equal' /home/travis/build/alphagov/whitehall/test/unit/admin/edition_filter_test.rb:27:inblock in class:EditionFilterTest'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/mocha-0.13.2/lib/mocha/integration/mini_test/version_230_to_2101.rb:36:in run' /home/travis/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1/test/unit/testcase.rb:17:inrun'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.1.12/lib/active_support/testing/setup_and_teardown.rb:36:in block in run' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.1.12/lib/active_support/callbacks.rb:426:in_run_setup_callbacks'
/home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.1.12/lib/active_support/callbacks.rb:81:in run_callbacks' /home/travis/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.1.12/lib/active_support/testing/setup_and_teardown.rb:35:inrun'

class Project < ActiveRecord::Base
  include ActiveRecord::Transitions

  state_machine do 
    state :started
    state :finished

    event :finish { transitions :to => :finished, :from => :started }
  end
end

class ProjectsController < ApplicationController
  def create
    @project = Project.new(params[:project])
    # need change state if params[:finish] = true
    # option 1
    @project.finish if params[:finish]  # state does not change
    # option 2
    @project.finish! if params[:finish] # state change, but will call save!, and throw an exception if the parameters are not correct
    ...
    # blah blah blah other actions with the model
    ...
    if @project.save # save call should be here
        format.html { redirect_to(@project) }
    else
      format.html { render :action => "new" }
    end
  end
end

More logical to do so:

p = Project.new
p.finish # true # state changes, save! not called
p.state # "finished"
p.save # true

p = Project.new
p.finish! # true # state changes, save! called
p.state # "finished"

@qoobaa I just checked and since 0.0.9 there have been significant improvements made - what do you think about a new release?
If you agree, I'd release 0.0.10.

We are experiencing issues on this on a table with a column named 'type' (for Rails STI). This table (invoice_settings) has no "state" column so why is this error happening?

This only happens when we do a InvoiceSetting.all or InvoiceSetting.first. I've searched around and it seems it has been an issue before but it seems it has resurfaced.

Will try to reproduce with a clean rails app later.

Is it possible to have more than one state_machine in a model.

How to setup (state column name, fire évents from this second state_machine ?)

Many thanks !

Points to http://github.com/qoobaa/transitions.

While attempting to use this gem I kept running into the issue where the persistence method with a bang(!) was not working.

In the README it talks about how "both events will call write_state_without_persistence on successful transition". What it does not say is that write_state_without_persistence is not defined for you in Rails or in the transitions gem. Which leaves the gem author to implement this method if the non bang-version is going to do anything other than set the @default_current_state instance variable.

I added the following to my ActiveRecord user class:

def write_state_without_persistence(sm, new_state)
  self.state = new_state.to_s
end

which does the trick, but it also means self.state= is called once inside write_state and again inside write_state_without_persistence.

I feel like I am missing something here. What is the proper way to use this gem with the non bang(!)-versions of the events?

This error has no useful context.

  raise InvalidTransition if transitions.size == 0

Including self.class.name and self.id along with the current state would be very helpful for debugging purposes.

Improve on those and switch to Rspec if possible.

I have Orders like this:
class Order < ActiveRecord::Base
include ActiveRecord::Transitions
When I create a new one (with just new, not create)
ruby-1.9.2-p0 > o = Order.new
=> #<Order id: nil, state: nil, user_id: nil, transaction_id: nil, created_at: nil, updated_at: nil>
ruby-1.9.2-p0 > o.state
=> nil
ruby-1.9.2-p0 > o.valid?
=> true
ruby-1.9.2-p0 > o.state
=> "started"
I see that set_initial_state is called by before_validation in the ActiveSupport::Concern. is it an easy fix to set the initial state during initialization, instead?

Hi,

i just run into this problem while trying to integrate sunspot in a rails3 project https://github.com/outoftime/sunspot
After executing "rake sunspot:reindex" it gives me this error:

rake aborted!
Transitions::InvalidMethodOverride

Tasks: TOP => sunspot:reindex

My Customer class - where the exception is thrown - looks like this

class Customer < ActiveRecord::Base
  include ActiveModel::Transitions
...
  state_machine :initial => :unregistered, :auto_scopes => true do
    state :unregistered
    state :registered

    event :register, :timestamp => true do
      transitions :to => :registered, :from => :unregistered
    end
  end
...
end

and the exception is thrown where the "state_machine" line is.

why is the exception thrown here? what can i do to fix this?

Consider the following code:

class Order < ActiveRecord::Base
  include Transitions 
  state_machine do    
   state :pending
   state :authorized
   state :paid
   state :payment_declined
   state :shipped
   state :delivered

   event :transaction_declined do
      transitions :to => :payment_declined, :from => :pending
   end

 end

end

o = Order.new
o.status # "pending"
o.transaction_declined # true
o.status # "pending"

I am using the 0.0.6 gem. What am I doing wrong?

Right now it's 1.0.1 when it should be 0.1.1: 8271a51#commitcomment-1802229

I have a state transition that sets an association in the model using :on_transition when going from state a to b. I have a validation that fails when the association is set and the state is still a. The problem is that when the validation is called during the state change, it should be valid, but because the state change hasn't happened (state attribute hasn't changed) the validation fails. Seems like the state machine should update the state attribute, THEN run validations, and finally, write the object. Why isn't this the case? In other words, the validations should have a way to know that a state change is occurring, and what the initial and target states are, just like the "dirty" functionality in ActiveRecord.

Since state events like :enter and :exit are triggered in fire_event it is not possible to manually set the state and enjoy the callbacks at the same time.

I'd like to be able to set the state in a virtual attribute and still have the callbacks triggered.

See: 882dd62

Would it be reasonable to pass the additional *args into transition.perform(obj) in lib/transtions/event.rb#L52? I have a use case where it would be nice to guard based on those additional arguments.

I'll write up a PR if you'd be willing to accept such a change.

Thanks!

In my model I had
include ActiveRecord::Transitions
state_machine do
state :submitted
state :valid
state :hidden
state :banned
end
And kept getting wrong number of arguments (1 for 0) until I renamed :valid to :validated . That closed an issue although word 'valid' isn't one of Ruby or Rails reserved words. There are many word exceptions for SQL databases but is that related to the particular field's value?

With the change from Rails 3.1.10 to Rails 3.2.13 i get following error when trying to run specs:

/.rvm/gems/ruby-1.8.7-p334@riptide/gems/transitions-0.1.8/lib/active_model/transitions.rb:34:in `old_transitions_initialize': stack level too deep (SystemStackError)

from /.rvm/gems/ruby-1.8.7-p334@riptide/gems/transitions-0.1.8/lib/active_model/transitions.rb:36:in `initialize'
from /.rvm/gems/ruby-1.8.7-p334@riptide/gems/transitions-0.1.8/lib/transitions.rb:45:in `new'
from /.rvm/gems/ruby-1.8.7-p334@riptide/gems/transitions-0.1.8/lib/transitions.rb:45:in `state_machine'

Im using Rails 3.2.13 and Transitions gem 0.1.8

StateMachine is defined as following in the model:

  state_machine do
    state :pending
    state :accepted
    state :terminated
    event :accept do
      transitions :to => :accepted, :from => :pending
    end
    event :terminate do 
      transitions :to => :terminated, :from => [:pending, :accepted]
    end
  end

The gem can't be released as "state_machine", a new name is needed before publishing.

Regarding: 90ff702

Implement scope generation like this:

• If the class already responds to a message, don't overwrite it
• Issue a warning
• make scope generation in general configurable

Regarding: 90ff702

Move logic to ActiveRecord::Transitions (lib/active_record/transitions.rb)

Currently transitions fixes the state column as "state". This is fine except for my model which already has a "state" attribute, as this is a common property of US addresses. I'd like to be able to say:

state_machine :column => :current_state do
end

or something like that.

undefined method `require_relative' for main:Object
/Users/mperham/.rvm/gems/ree-1.8.7-2012.02@theclymb3/gems/transitions-0.0.14/lib/active_record/transitions.rb:1

It would be nice if the column name matched the name given when calling

state_machine :altenative_name

It would be nice to know how to use this gem. An example class in the README and/or some inline docs would go a long way.

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

-> https://github.com/qoobaa/transitions/pull/14

I discovered that (though I cannot confirm 100%) that under mysql 5.0.x, if in the migration I set :null => false for the :state field, BUT don't provide a :default value on the migration, transitions doesn't set the initial state for the Model and it fails to be created.
This didn't happened on mysql 5.1.x.
I wrote a test here:
git://github.com/Porta/test_null_without_default.git
In case you'd like to test it.
Let me know if I can do anything else.

When an invalid transition is made, the error message is hardly helpful because the 'to_state' part is always nil in the call Transitions::Event#fire(machine.rb:50), thus the error message is always looks like this: "Cannot transition to default from failed for Server with ID 112112".

I'd suggest include the event name in the error message at least.

Do you guys have any plans on supporting mongoid?

I found a fork here that supports it:

https://github.com/netizer/transitions

I would be great if you could add it in.

Best,

Aaron Qian