We just ran into a rather annoying gotcha when upgrading our application from Rails 2.0.2 to 2.1. All of a sudden, a few the columns in a few of our ActiveRecord classes unexpectedly started defaulting to nil, and refusing to save with a MySQL error. We tracked this down to a change in how ActiveRecord 2.1 is handling default values for BLOB and TEXT columns in a MySQL database.

Background

ActiveRecord uses the database schema to automatically “construct” classes and populate default values. For the most part, this works great. You can create a table such as:

  CREATE TABLE `first_objects` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
    `number_field` INT NOT NULL,
    `string_field` VARCHAR(100) NOT NULL DEFAULT 'hello',
    PRIMARY KEY  (`id`)

…

Comment your code—it’s a mantra they drill into you in Programming 101. I know, most of us took that class at age 5 or 6, but it’s still important 30 years later.

Of course, in those bygone days, we were probably programming in C (or maybe Java for you young’uns, or FORTRAN for the graybeards). Comments were there for your benefit as a programmer, and the compiler helpfully threw them away when building binaries for end-user consumption. You could put anything you wanted into your comments and not worry about them becoming public knowledge. Anything, including:

C XOR WITH 42405 TO ENCRYPT MY SECRET VALUE

or

/* This paranoid and performance-killing logic is here because
   the customer is a clueless f***ing anal-rententive nutcase. */

or

// I have a...

For people like me with a Java background, one of the first things we bemoan and disparage when learning Ruby is its thread support. Simply put, Ruby threads are green threads, meaning they are implemented in user space. Among other things, this means they cannot be scheduled onto multiple processors or cores because the operating system does not know about them.

There are other issues, such as the fact that often-used libraries such as ActiveRecord are not thread-safe. This article gives a brief but fairly good overview of the issues, relevant to the current MRI 1.8 implementation. InfoQ also published a very interesting article last spring on the pros and cons of…

It’s amazing what you find if you just bother to look.

I was updating Zoodango’s internal rdocs, and I got thinking, the layout that rdoc generates by default is not how I’d do it. I often have fairly long lists of files, classes, modules, and methods, and the three scrolling lists across the top are too small to scroll effectively. Just try scrolling through the class list on the Ruby core library rdocs and you’ll see what I mean.

Most people’s screens and browser windows are horizontal, so I couldn’t understand why the template would take up valuable vertical real estate in that way. The rdocs for Rails look much better—moving the scrolling lists to the left side. Not to mention that the formatting looks quite a bit…