4 ms·

Hello! I have performed two rails 2 upgrades. Both cases they were smallish apps, but they took 3-5 days to feel comfortable with everything that's happened.

by phillmv 13y ago

Hello! I have performed two rails 2 upgrades. Both cases they were smallish apps, but they took 3-5 days to feel comfortable with everything that's happened. If this is an app that is still being actively developed, I highly recommend you fast track it. [If not, look up the community-managed security back port branch and switch to that asap] Basically, the problem stems from bit-rot and alas such is the nature of our industry. In a nutshell, the longer you wait the harder it is to find quality docs on what's changed and how to fix it. A lot of links are now gone. The main challenge comes from: the change in the router, the changes in the view api (everything is escaped by default, and you will find a ton of string concats in your helpers that will now spit out garbage), migrating over to the asset pipeline (which I personally found confounding for a long time until I got the hang of it), migrating over to Arel queries and updating all of your plugins - many of which will stop working in quirky ways. You may also experience pain with updating your test suite. So, there's a lot of yak shaving but you don't actually have to refactor your app much. Your controllers will remain basically untouched and so will your models modulo named scopes and certain now preferred validation patterns. Most of the pain is view-focussed. Oh, and the attribute protection but that pain is a good pain, you really need to whitelist your attributes. IF YOU ARE READING THIS MAKE SURE YOUR MODELS HAVE AN `attr_accessible` THAT DOES NOT HAVE ANY ATTRIBUTE THAT ENDS IN `_id`. There's a phenomenal plugin that will help a lot - https://github.com/rails/rails_upgrade https://github.com/rails/rails_upgrade - but it's not going to catch everything.

pjungwir 13y ago
I'm a stickler for attr_accessible, but I've never heard of avoiding _id attributes. If a have an Employee model, what is wrong with `attr_accessible :department_id` (assuming I want to permit changing the department)?
- phillmv 13y ago
  It depends on your app. Suppose you have some kind of permissions model based around the department that a certain employee belongs to. Say, HR people can look at people's salaries. If you allow mass assignment to department_id, someone can edit the form in the user page and assign themselves to ANY department and boom!, they're in. You can fix this by having some sort of validation, but I find I prefer to have it in the controller. Before: @model.update_attributes(params[:model]) # trololol After dept = params[:model].delete[:department_id] @model.update_attributes(params[:model]) if current_user.can(:foo) @model.department = Department.find(dept) end If I've got this wrong, please let me know. I'm pretty sure the above is basically the whole point of using attr_accessible (aside from the fact that they now force you to use it; was not the case <3.2 iirc)
  - pjungwir 13y ago
    Okay, so it just comes down to whether or not the user should be allowed to edit the FK relationship or not. You may be interested to know that you can have multiple attr_accessible declarations for different classes of user, and then when you call update_attributes you say which declaration should apply. But perhaps with strong parameters it's not worth going down that road.
johnbellone 13y ago
The problem that we run into is that most people haven't upgraded a 2.3 application that is our size. We're already aware of the community-managed backports, but ideally we will just be able to fast track moving towards 3.2 soon. We have actually backported sprockets/asset pipeline quite awhile back and have been using it without any major problems. Definitely aware of the benefits its just very hard to do something at the scale that we're at :). Earlier this year our REE -> 1.9.3 upgrade took about a month and a half. For the past year we've been moving to separate, smaller applications and then breaking those into mountable engines within each application. Appreciate the feedback though and the links!
- alxndr 13y ago
  Some folks from New Relic gave a talk at RubyConf this year about upgrading their old-for-Rails project from 2 to 3, I found it pretty informative http://www.confreaks.com/videos/2425-railsconf2013-changing-the-wheels-on-the-bus-at-80-mph-upgrading-to-rails-3-on-a http://www.confreaks.com/videos/2425-railsconf2013-changing-...
- johnbellone 13y ago
  I'll watch that video! Thanks!

by phillmv 13y ago

pjungwir 13y ago

I'm a stickler for attr_accessible, but I've never heard of avoiding _id attributes. If a have an Employee model, what is wrong with `attr_accessible :department_id` (assuming I want to permit changing the department)?

phillmv 13y ago
It depends on your app. Suppose you have some kind of permissions model based around the department that a certain employee belongs to. Say, HR people can look at people's salaries. If you allow mass assignment to department_id, someone can edit the form in the user page and assign themselves to ANY department and boom!, they're in. You can fix this by having some sort of validation, but I find I prefer to have it in the controller. Before: @model.update_attributes(params[:model]) # trololol After dept = params[:model].delete[:department_id] @model.update_attributes(params[:model]) if current_user.can(:foo) @model.department = Department.find(dept) end If I've got this wrong, please let me know. I'm pretty sure the above is basically the whole point of using attr_accessible (aside from the fact that they now force you to use it; was not the case <3.2 iirc)
- pjungwir 13y ago
  Okay, so it just comes down to whether or not the user should be allowed to edit the FK relationship or not. You may be interested to know that you can have multiple attr_accessible declarations for different classes of user, and then when you call update_attributes you say which declaration should apply. But perhaps with strong parameters it's not worth going down that road.

johnbellone 13y ago

The problem that we run into is that most people haven't upgraded a 2.3 application that is our size. We're already aware of the community-managed backports, but ideally we will just be able to fast track moving towards 3.2 soon. We have actually backported sprockets/asset pipeline quite awhile back and have been using it without any major problems. Definitely aware of the benefits its just very hard to do something at the scale that we're at :). Earlier this year our REE -> 1.9.3 upgrade took about a month and a half. For the past year we've been moving to separate, smaller applications and then breaking those into mountable engines within each application. Appreciate the feedback though and the links!

alxndr 13y ago
Some folks from New Relic gave a talk at RubyConf this year about upgrading their old-for-Rails project from 2 to 3, I found it pretty informative http://www.confreaks.com/videos/2425-railsconf2013-changing-the-wheels-on-the-bus-at-80-mph-upgrading-to-rails-3-on-a http://www.confreaks.com/videos/2425-railsconf2013-changing-...
johnbellone 13y ago
I'll watch that video! Thanks!