Hacker News Reader

Comment by jarin | Hacker News Reader

Uh oh, I haven't even updated my clients to Rails 3.1 yet. Definitely not good to fall behind more than a major point release or two with Rails. I have a very old client running Rails 2.3.x and it's always a pain when they need the occasional update and Rake doesn't even work anymore.

View on HN

It sounds like you're not using rvm and gemsets (or a similar tool) for your Rails 2.3.x sites. Rake should never "stop working".

http://beginrescueend.com/

Unless you're on a platform where you can't get gcc >4.0, so RVM is helpless, and you're stuck with just bundler. Then the rake/cron nightmares come..

As I understand it, a lot of work has been put into Rails 3.x series so that it is easier to upgrade your apps.

It should be a lot easier to go from 3.0 to 3.1 or 3.2 and hopefully from 3.0 to 4.0.

I do hope they improve their policy on regression-tests and upgrade instructions. 3.0 -> 3.1 wasn't very smooth for me, the bugs were just more subtle.

My favorite bug during the upgrade: Someone decided (long ago) it'd be a good idea to store a Marshalled object in the session-cookie. One class serialized therein disappeared in Rails 3.1. Result? Any and all requests with a session-cookie bomb out with an unmarshall error.

tldr: Make sure to rename your session cookie before rolling out the upgrade. This logs out all users but is still more desirable than the alternative...

IMHO the better solution would not to store marshalled objects in the session cookie. Especially ones that you don't have direct control over. There can't be any reasonable regression-test or upgrade test that could test for this.

The Rails flash is actually stored as a marshaled object in the cookie, so this broke for everyone who happened to have something stored in the flash at the time of upgrade (which is a lot of people). It should have been caught before but it did get fixed in the latest release.

I feel your pain, I have a bunch of legacy 2.2 and 2.3 apps.

I moved all dependency management from config.gem over to Bundler, and haven't had a dependency issue since.

I wish I was still on 2.3. I made the jump and am now running 3.1, after putting off upgrading for so long. I bit the bullet because most plugins simply don't backport bug or security fixes. But hardly a day goes by that I don't wish I was still on 2.3.

Why ? I found 3.1 upgrade with all the asset compilation etc, a bit painful but 3.0 brought in a lot of nice changes. (Arel for one)

It's considerably slower than 2.3 and the API fell apart. It's this weird system that looks modular, but including any given module into your code will almost certainly fail due to weird dependency graphs or because some modules seem to only work when injected into certain classes. This makes it incredibly frustrating to debug.

Generally I like Arel, but the changed behavior around default_scope is maddening. And I've found several pretty big bugs that have been annoying to work around.

"Generally I like Arel, but the changed behavior around default_scope is maddening. And I've found several pretty big bugs that have been annoying to work around."

Can you expand on this?

Sure. I usually add a :default_scope with an order clause to my models, since it makes using :first and :last considerably nicer. If you want to do sort in the opposite direction, you can't just add .order to your calls (this used to override the default scope in Rails 2.3), since Arel will just translate that to the senseless "ORDER BY id ASC, id DESC".

The way around this is to use :reorder, but :reorder doesn't work the same way and can generate invalid SQL if you're prefetching included associations. So, you're left with :unscoped, but that's insanely insecure because it drops any foreign key scopes you had in place.

Likewise, it only normalizes identical order clauses if you use the exact same casing. This one is a bit more esoteric, but if your default_scope is to order by "id asc" and you reorder by "id ASC", Arel will produce "ORDER BY id asc, id ASC". If they match in case, however, it'll be normalized to a single clause.

I haven't found the time to attempt a proper fix to any of these problems yet.

@jonleighton committed a big refactor yesterday that might be a good sign here; looks like a lot of the old monolithic AR code is now new-style Concerns, more of a defined API, etc. If the root problem here is ARel itself, that won't help, but if it's really AR::Relation, maybe Rails is moving in the right direction.

We use user-defined functions in Postgres, and I have the same complaint - in theory, the move toward composable relations is great, but in practice, there are so many hitches and gotchas and prior assumptions and backwards-compatibility requirements that it's never clean.

Reply on news.ycombinator.com