Posts Tagged ‘Rails’

Renaming a database in Rails

December 14th, 2009

Hooray for a non-rant post!

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.

uninitialized constant Thin::Server::Forwardable

July 2nd, 2009

I may be getting batty in my old age here, but for whatever reason Thin decided to just stop running on my system.  When trying to invoke thin to further development on the code behind my awesome website, I was treated to the following:


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.

Debuggin’ in Rails

December 26th, 2008

This is a for-my-benefit-reference post like the last 2.  Perhaps I’ll do a better write-up of ruby-debug at a later time.

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

Production mode cluster conundrum

July 16th, 2008

I wish I had some cool screenshots for this one, but hopefully a text-based description will suffice.

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.