Upgrading Legacy Applications: Ruby 1.8 Pitfalls

When dealing with large, long-lived enterprise apps, the upgrade cycle is often much slower.  Because these applications aren't always under active development, the prospect of "long-term support" releases becomes more important.

We recently upgraded a client app from Ruby 1.8.7 to Ruby 1.9.3, just as support for Ruby 1.8.7 was ending.  We ran into some "gotchas" while upgrading, so perhaps these will help other developers in the future.

In general, the incompatibilities between Ruby 1.8 and 1.9 are well-known, but we discovered a few lesser-known issues during this upgrade.

1. Array#to_s

In Ruby 1.8, calling to_s on an Array is equivalent to calling join.

In Ruby 1.9, calling to_s on an Array is equivalent to calling inspect.


This seems like a minor change, but it is significant.  There are many Ruby 1.8 libraries that will display arrays directly to users via to_s, assuming the array will be suitable for display directly to an end-user.

If that code is run against Ruby, 1.9 the displayed array will include both the brackets and commas, usually making it unsuitable for end-user display.

2. Symbol#to_i gone

As of Ruby 1.9.2., symbols are no longer internally represented as integers and Symbol#to_i was removed (thanks to andrewjgrimm for pointing this out).  Thus, if you call string_object[:symbol], it will use the symbol's integer representation to reference an element under Ruby 1.8.

3. Creating Hashes

In Ruby 1.8, you can actually create a hash by putting an list of keys and values directly in the curly braces. In Ruby 1.9, that doesn't work.

KEY TAKEAWAY

Backwards compatibility in languages is important, especially when building enterprise applications.  Even if a seemingly-arbitrary change looks like a net win for program correctness, it can cause problems in legacy software.

For example, consider the following code:

Let's say you have a bug in method_that_returns_a_hash, and it sometimes returns a String instead.  Under Ruby 1.8, that bug might be completely innocuous, because address_map[:canada] would still return nil, and your program could still execute correctly.  Under 1.9, that would raise an error.

What other obscure incompatibilities have you encountered while upgrading legacy software?

Oracle on Rails: Can Proprietary and Open-Source Play Nice Together?

We're starting a new enterprise Rails project at Panoptic Development (that's right, enterprise Rails), and we're using the Oracle database. Yes, we all know that Rails plays best with other open-source databases like PostgreSQL, but sometimes development teams don't have the luxury of choosing the database.

The upshot of all this? We'll hopefully be contributing some articles and open-source code to help other developers work with the proprietary, enterprise behemoth that is the Oracle database.

I've started with a quick fork of Raimonds Simanovskis' useful rails_3_oracle_sample application, adding some documentation that helped me get things started.

Raimonds seems to be working harder than everyone else to integrate Oracle with Ruby on Rails, so check out his excellent blog.

Most Rails developers work in small, agile teams without a dedicated DBA, and that's often quite different from the workflow in large organizations using Oracle. Here's one of Raimonds' presentations (from three years ago!) that helped get me into the Oracle mindset:

Using Ruby on Rails with legacy Oracle databases

View more presentations from rsim.

Stay tuned for more updates.