Well, you too can have access to what Rails uses to put deprecation warnings in the log file.

ActiveSupport::Deprecation.warn("Stop calling me!")

It of course takes a good team policy to require all such warnings to be removed, but I was delighted to find that this is readily available and usable for my own deprecation warnings. It sure beats using Rails.logger, because the intent is clearer, and such warnings will get shut off when all deprecation warnings are turned off anyway.

I had a before_validation callback on an ActiveRecord model. I was running in test mode using Shoulda and FactoryGirl, so I figured those 2 gems had something to do with it. Then came the humble pie.

I also had a validates_presence_of on the model, and it was getting called before the before_validation callback. The test wasn’t setting that attribute, so naturally I never got to the callback.

Once again it was not a cloud if improbability that caused the universe to collapse around me. It was a bone-headed error.

The heart of this method works outside of Rails, but there’s one particular convenience method that Rails provides.  Find some way to mimic that behavior, and the rest would apply.  Also, this is a MySQL-specific solution.  I haven’t tried it with any other DB systems.

We “rename” a database by moving all of its tables into a new database.  We do so via MySQL’s RENAME TABLE command.  Basically, create an empty database with the new name.  We then use our ActiveRecord connection’s “tables” method to loop over all the tables in our database, executing a RENAME TABLE from the old to the new with each iteration. “Tables” is the convenience method I mentioned above. Encapsulating this in a method we get:

def rename_database(old_db_name, new_db_name)
    ActiveRecord::Base.connection.execute "CREATE DATABASE #{new_db_name}"
    ActiveRecord::Base.connection.tables.each do |table|
        ActiveRecord::Base.connection.execute
            "RENAME TABLE #{old_db_name}.#{table} TO #{new_db_name}.#{table}"
    end
    ActiveRecord::Base.connection.execute "DROP DATABASE #{old_db_name}"
end

Error checking is left as an (important!) exercise to the reader.  Also, you may prefer to monkey patch this into ActiveRecord itself as opposed to some odd method floating around in global space.

This presupposes that the new database destination will be on the same server.

Another way to rename a database is to mysqldump the old one to a file and then reimport it to the renamed database.  The method presented in this article is advantageous if your database has a large amount of data.  Renaming a table is almost instant.  Dumping millions of rows and reimporting them is not so instant.


ethan:ethang juanpaco$ thin start
/Library/Ruby/Gems/1.8/gems/thin-1.0.0/lib/thin/server.rb:51: uninitialized constant Thin::Server::Forwardable (NameError)
from /Library/Ruby/Gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:38:in `initialize'
from /Library/Ruby/Gems/1.8/gems/thin-1.0.0/bin/thin:6:in `new'
from /Library/Ruby/Gems/1.8/gems/thin-1.0.0/bin/thin:6
from /usr/bin/thin:19:in `load'
from /usr/bin/thin:19

I didn’t like that.

I went to the line number where the error occurred (/Library/Ruby/Gems/1.8/gems/thin-1.0.0/lib/thin/server.rb:51), and found:
extend Forwardable

Not knowing what Forwardable was, and for giggles, I went to irb and typed “Forwardable” thinking I’d get the class object.  Not defined.  So I try “require ‘forwardable’.”  There was no period in what I typed, but I haven’t figured out how to get Ruby and English to play well together.  Anyway, that worked, and a subsequent typing of “Forwardable” returned the object. So then I tried putting require ‘forwardable’ at the top of server.rb in thin’s gem.

And then it worked.

I’m not sure why it used to work and then suddenly didn’t.  This was after several install/uninstall, swear off programming moments.  Weird.  So, if you’re struggling with this same problem, perhaps the above can be of service.

“info breakpoints” to see the list of set breakpoints.

So I fixed a bug at work, where certain AJAX calls were failing.  It turns out that our view templates were making some assumptions that they ought not to have been making.  I fixed that error, and our QA team pushed that code out to our test servers (along with other things– I wasn’t that important).  Well, the error, or at least its symptoms, showed up again.  Now, it only showed up sometimes, and only on the test server.  “It works on my machine,” not being much of a solution to a bug, I started investigating.

I looked into the error logs that were being generated, and saw what looked like the sort of error you get when you call a helper method which doesn’t exist.  As part of the bug fix, I added a helper method.  We checked manually the code that was running on the server, and it had the helper method and the full new version of the code.  At this point I began suspecting the work of some foul dark wizard– or at least a gremlin.  I mean, why else would a view template not be able to find a helper method that is there after the server has been restarted?

I’ll tell you why.  We have a cluster configuration, and Capistrano or something else, hadn’t shut down every process running the old code.  Since AJAX calls are full-blown server requests that just happen not to refresh the whole browser page, some of those calls were directed to server processes that hadn’t actually been restarted.  Rails doesn’t auto-refresh code in production mode (Good Thing), so those old processes quite naturally didn’t find the new code.  We killed the old processes and, presto!  The world is right again.

So, if you ever find yourself wondering why your view template can’t find your helper method, check to make sure that your server restart restarted ALL instances of your application. We’re still not entirely sure why all instances didn’t restart though.

So, Dark Wizards may still be involved.