Heading into Rails TOOOOOO-TOOOOOO-TOOOOOO!

When I played little league baseball we had announcers for the game, one of which was some nice old guy in a ramshackle shelter behind home plate that was the “booth” – and every time there’d be two outs, two strikes and two balls – he’d croon “TOOOOO-TOOOOO-TOOOO”. Which of course, has little to do with this post other than version numbers.

Rails 2.2 was just released – so of course, I’m taking the most critical application we have (well, maybe the second critical, and that’s really only because other apps depend on it, it’s not critical in terms of features) – and upgrading it first, because, well, that’s how system administrators roll.

The release notes are great. Seriously. Really great. So great I shouldn’t even be writing this post. Which I am anyway – because here are some of the highlights of what I had to change to make my app work.

NoMethodError for Association Methods

Getting exceptions when you go to Rails 2.2.2 that don’t say anything more than NoMethodError when you know good and damn well the method that it’s saying no method on exists? Yeah, me too. And I bet it’s a method in an associated model. And if it is, you probably should be ashamed of yourself.

Rails 2.2 now enforces privacy on private methods called through associations. So in my case, I had two issues, 1) I was calling “update” on an associated model in some code I blindly copied and pasted a long time ago, and 2) I have a few of my own SQL queries that I’m not entirely sure how to do using Rails associations and named scopes, and I was cheating by calling self.connection.sanitize_limit to take advantage of Rails’ own function for cleaning up provided “LIMIT” params. And sanitize_limit, like the instance method update is private.

Update Rails Footnotes

If you use Rails footnotes in development mode – you’ll want to update for this change for Rails 2.2 compatibility.

Aside… Piston 1.9.5

A great way to stay current with Rails plugins is to use Piston – which has a new 1.9.5 release. You can build your own.

“quoted_table_name” and Has Many Polymorphs

If you start getting some error about undefined method `quoted_table_name' and you use has_many_polymorphs – you’ll want this change.

I don’t use the plugin, I use the gem. So I built my own has_many_polymorphs 2.12.1 gem – by doing:

gem install echoe
git clone git://github.com/fauna/has_many_polymorphs.git
cd has_many_polymorphs


edit CHANGELOG with a “v2.12.1 line” (e.g. v2.12.1. Cloned GitHub project and rebuilt gem for our nefarious purposes.)


rake manifest
rake package
rake install


add_joins! and Has Many Polymorphs (or anything else for that matter)

HMP includes a ‘tagged_with’ method for finding collections ‘tagged_with’ a set of tags. I use a heavily modified version of that. The method supports custom scopes, in theory. (well, probably more than theory, I’ve just never tried it). While, I don’t have any scopes on models that call my functions – I still had some of the private ActiveRecord method calls in mine – particularly add_joins!.

Well, this change changed the params for the method to make sure that the scoped joins were merged, and not overwritten – which changes calls into it. If you are calling it with your own options use options[:joins]. My code doesn’t use the scopes in combination with my tagged_with method, so I just pulled them.

And…. thankfully that’s it

Other than cleaning up deprecations like number_with_precision now preferring (number, :precision => myprecision) instead of (number, myprecision) – and ActiveRecord::Base.verification_timeout no longer valid, and mb_chars being preferred over chars – we seem to be good to go for Rails 2.2. I still need to test some crons, but I imagine that our app will go production as 2.2 shortly.

TOOOOOO-TOOOOOO-TOOOOOO!

Don’t Do That

So… maybe you are coding up your totally way rad awesome application in Rails – and you are thinking to yourself.

“Self, I really would like to set my own created_at and updated_at timestamps. Look – there’s even a way to do that in the Rails documentation”


class Feed < ActiveRecord::Base
self.record_timestamps = false
# ...
end


At this point you need to back away from the keyboard. Quickly. If you don’t, pretty soon, somewhere in your application – you are going to run into this error:

Mysql::Error: Column 'created_at' cannot be null

Or ALL KINDS OF OTHER FUN SIDE EFFECTS (FUN is actually a euphemism here for various four letter words)

See, record_timestamps is a class variable for ActiveRecord::Base created with the rails :cattr_accessor – maybe the self.record_timestamps should have tipped us all off – maybe not (there’s also a class_inheritable_accessor – I’m not sure where all that gets used though)

Even experienced developers not all that fluent in ruby minutiae (I think class variables count as minutiae) cut-and-paste first and figure out how it works second (yeah, don’t do that either).

So – anyway – once you change record_timestamps once – you change it for all descendants of ActiveRecord::Base

There’s a bit of discussion this on a separate, but related problem at Evan Weaver’s blog (pay special attention to that threading issue for those playing along with the home game). And of course, your friendly neighborhood reminder of what happens with class variables at Nic Williams’ blog (I recommend reading that twice and breaking out the home game version of irb)

So the moral of the story? self.record_timestamps – Don’t Do That.

p.s. Production of this blog entry was made possible through various grants and assessments, and with some moans, groans, sighs, and “what tha–?” from my colleagues James Robinson and Aaron Hundley (doesn’t have a blog, he needs to get with the program)

p.p.s edited to change “you chance it for all descendants…” to “you change it for all descendants” – I think the first one is quite apropos however