We have an app that I upgraded to 2.0 during it’s infancy about a year ago. Since then 2 versions have been released (2.1.x and 2.2.x) and a third one is looming on the horizon (2.3).
I read a blog post that recommended upgrading to 2.1.2 en route to 2.2. That way you could see what messages you get about things that will be deprecated. I chose this route.
Along the way I learned a couple of lessons….##2.1.2##
Lesson 1. We use subversion for our version control. I did not create a branch to do all this work. Bad idea. You will see why, specifically, at the end. I just busted right in.
The upgrade itself was pretty easy. There were some quirks with subversion once I froze the rails gems because I had not deleted the older version. Subversion thought they were still under control. And somewhere along the line I confused subversion and deleted the vendor directory. That’s right. All of it. Damn!
There were a few ideas introduced with 2.1.x that I updated in the app immediately.
- Inflector became ActiveSuppor::Inflector. This is actually something that we use.
- The environment.rb file got a little cleaner with the introduction of initializers. We had some of that, so it got moved out.
- You can also specify the gems that your app uses in the environment.rb file with config.gem. Did that.
- nestedhasmanythrough was out of date and needed to be updated from source (github).
- Finally, I had to update rubygems itself.
I created a test app to see what it looked like to make all of these things easier.
The app ran, but there was a form that needed to be updated. I don’t remember the specifics, but it was no big deal.
2.2.2
Woo Hoo! We’re cooking now! Same process as above, but this would not be my first rodeo. I knew the drill.
Things that changed with 2.2 were:
- Locale/time zone support. We were using the tzinfo gem, and I had a config.gem entry for an older version. It was cool for me, but my coworker had the newer gem on his system and it bitched at him. After a little digging we discovered that it’s included in ActiveSupport now, so we deleted our unpacked gem.
- Argh! That stupid new migration name format. Config setting to revert to the same way. Check.
- Gem .specification file now required. No worry, rake can make it for you. Unless you’re talking about RMagick. Then even though it runs fine rails will bitch. Rather than recompile ImageMagick and the newest version of RMagick, I just commented out the config.gem line. I am OK with that. It does work, afterall.
- The truncate helper now works differently, so I changed that in the few places we use it.
- The ARTS RJS testing plugin is out of date, but there is a hack for it to make it happy. Check.
Tested and checked in.
The Problem
I was telling my coworker how great the upgrade went Monday morning and made an offhand comment about how I had to change this one finder call to include a related table because it on;y pulled a single record otherwise. No biggie I thought. WRONG
We use Sybase, and the Sybase rails adapter is not very well supported. And it turned out that it was broken with respect to QueryCache. If the rowcount was set to 1 then that would be the resultset that was cached. Any subsequent requests of that resultset would get just the single record.
My very smart coworker, who I think was pretty well pissed (at me), managed to find a way to beat this cacheing bug that only happens for Sybase. Problem resolved, please resume normal programming.
If I had created a branch we could have tabled this for the time being until he finished the stuff he was working on that is due pretty much right now. I didn’t.
Lessons Learned
- Branching may be a pain, but the alternative is more of a pain.
- The devil is in the details
- When you’re collaborating with someone or a team, it’s really freaking important to communicate what you’re doing and make sure you’re all on the same page.