Archive for December, 2009

Paperclip/ImageMagick/RMagick error: “is not recognized by the ‘identify’ command”

December 30th, 2009

If you’re using the above combination, and you’re getting the above error, make sure that you’ve configured Paperclip to find ImageMagick in the right place.  Create an initializer file, RAILS_ROOT/config/intializers/paperclip.rb, and put “Paperclip.options[:image_magick_path] = ‘path/to/image_magic’” inside of it.  On Mac or a *nix system, type “which identify” to find the right folder.

Big thanks to avit on this forum for the solution.

shoulda and factory_girl not cleaning up db between tests

December 22nd, 2009

Wow, this one was a doozy. I recently (yesterday) had my first introduction to shoulda and factory_girl for testing. I’m torn as to whether or not fixtures are the root of all evil, as I haven’t really encountered problems with them and find them very simple to use and maintain, but that isn’t the point of this post.

The point is that just starting a new job I figured a good thing to do was first run the unit tests to make sure I had set up the app properly. I was treated to many failures and investigated why. I found many failures caused by a polluted database. Previous tests weren’t cleaning up after themselves, so later tests had bad state (duplicate records and that sort of thing). While that may be a plug for database level enforcement of that kind of rule, that task was beyond the scope of what I was doing.

I scoured Google looking for answers, and a day later I finally found it. Just to stretch you along even further, here’s what it wasn’t:

  • shoulda not running implicit teardowns
  • transactional fixtures being turned off

No, it was a great deal dumber than that, and a thanks to Eric Artzt, whoever you are, for providing the solution. The table that was giving me fits is a MyISAM table, which doesn’t support transactions. Which means there are no rollbacks to clean up my DB state. Which means I either have to explicitly put calls to do that into an explicity-defined teardown method or switch the engine on the table in question.

Installing Ruby gems that require building native extensions on Snow Leopard

December 18th, 2009

I haven’t tested this on all “machines” running Snow Leopard, but on the brand new one I had to get today for work, I found that the default Ruby / Gems install doesn’t support installing gems that require building native extensions. The error message I was treated to contained the following:

MacBook-Pro-de-Ethan-Garofolo:~ juanpaco$ sudo gem install thin
Password:
Building native extensions. This could take a while...
ERROR: Error installing thin:
ERROR: Failed to build gem native extension.

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb install thin
mkmf.rb can't find header files for ruby at /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ruby.h


Gem files will remain installed in /Library/Ruby/Gems/1.8/gems/eventmachine-0.12.10 for inspection.
Results logged to /Library/Ruby/Gems/1.8/gems/eventmachine-0.12.10/ext/gem_make.out

The solution was hyper-intuitive. Install XCode. Because of course that's the first thing you think of.

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.