Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
In this case, the same table is used to store data about both Users and AdminUsers. Generally, the 'type' field is used to tell the difference between Users and AdminUsers, by storing the class name of the object being saved (i.e. 'AdminUser'). This all works out fine 99% of the time. When you create a new model that uses STI, ActiveRecord presumably takes care of setting up a default value for the column and marking it as non nullable, etc.
class User < ActiveRecord::Base ... end class AdminUser < User ... end
ActiveRecord tries to insert a new row, setting the type column to NULL, which is a horrible way to store data for an STI model! Fortunately, in my case, type is a non-nullable column, so I get an error.
ActiveRecord::StatementInvalid: Mysql::Error: Column 'type' cannot be null
I thought this was all I had to do, but it turns out running db:test:prepare just matches your test database to your schema.rb file, and my schema.rb file hadn't been updated, so now User.create is working fine in development, but broken in testing, and THAT kind of failure is the most fun you can possibly have trying to debug a test: the kind that only happens in the test environment! :D
mysql> ALTER TABLE users MODIFY COLUMN type varchar(50) NOT NULL DEFAULT 'User'; ...[ok] mysql> exit Bye $> bundle exec rake db:test:prepare # <-- My Mistake ...[ok]
|Starting with Ruby on Rails||2,721|
|Spring Hibernate Integration||5,026|
|WHY MVC is the future technology...||3,030|
|How to process returned pointer structure data from Windows DLL in Ruby||4,262|