3 ms·

My company is still on Rails 3.2. We had been waiting for the first minor release of Rails 4 to give folks a chance to work out issues, so maybe now it's time t

My company is still on Rails 3.2. We had been waiting for the first minor release of Rails 4 to give folks a chance to work out issues, so maybe now it's time to look at upgrading. Anyone have major issues going from 3.2 -> 4? I've heard horror stories about 2 -> 3, but I didn't pick up Rails myself until 3.x so I don't have firsthand experience. The biggest change I see is attr_accessible to strong_parameters. Does that mean I need to go through and rewrite all our models and controllers before we can update?

dkokelley 13y ago
I'm not 100% sure, but I believe you can upgrade without a lot of rewriting by using the protected_attributes gem (https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes).
kyleashipley 13y ago
3.2 -> 4 is an order of magnitude easier than 2 -> 3. The upgrade guide is pretty solid, and I imagine it mostly applies for Rails 4.1 as well: http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-3-2-to-rails-4-0 http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#u... I spent most of my time updating app config. For several of my 3.2 apps, I started using strong_parameters, so it wasn't a leap for me. Another app I have on 4.0 is using the https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes to retain the existing attr_accessible behavior until I get time to update. Hope that helps!
mountaineer 13y ago
I'm working on an update too, and am biting the bullet and rewriting the strong_parameters/attr_accessible parts. But, you can in theory use the Protected Attributes gem to aid migration with less rewrite.[1] [1] http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...
kule 13y ago
It's a way smoother upgrade - exactly as you mentioned really the only major change is from attr_accessible to strong parameters however you can still include the protected attributes gem for a quicker/easier upgrade path (https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes)
latortuga 13y ago
It does not, you can actually pull in a gem[1] to use attr_accessible just fine with Rails 4. If you want to transition to strong_parameters, you can include the gem in your Rails 3 project and begin migrating to it, though that's a tough sell on most Rails codebases I've seen as it requires you to update every action in your app. I have not personally migrated any of my code to Rails 4 from 3.2 yet but the transition will be far smoother than 2.3->3 was. [1] - https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes
phereford 13y ago
You are correct that attr_accessible is gone in favor of strong parameters. Google fu yields http://stackoverflow.com/questions/17371334/how-is-attr-accessible-used-in-rails-4 http://stackoverflow.com/questions/17371334/how-is-attr-acce... Depending on how your test suite is set up (if you have one) there may need to be some sweeping changes there. When we migrated we had to switch from our should syntax to the expect s syntax. I can't remember anything else that was super crazy.
patrickdavey 13y ago
The railsdiff website is also a very handy little tool for quickly seeing the differences in config between versions: http://railsdiff.org/diff/v3.2.17/v4.1.0/ http://railsdiff.org/diff/v3.2.17/v4.1.0/
- harrylove 13y ago
  https://github.com/rails/rails/compare/v4.1.0...v3.2.17 https://github.com/rails/rails/compare/v4.1.0...v3.2.17
  - timdorr 13y ago
    Railsdiff.org just shows you what's changed in the generated app files, not the actual libraries.
mbesto 13y ago
My co-founder wrote a book on exactly this. In case you're interested: https://leanpub.com/upgradetorails4 https://leanpub.com/upgradetorails4
jfaucett 13y ago
Also be wary of your projects Gems, we just finished a 3.2 to 4.0 upgrade and though rails itself was pretty easy, there were quite a few problems with things such as Solr, Formtastic plugins (some FormTag internals changed in rails4, which broke some stuff). So yea, the biggest problem was upgrading to Rails4 and getting the Gems to work- many of which had large structural changes in the Rails4 versions. For instance, Devise changed how they handle tokens in the Mailers, etc. We have a very large App and it took us about 2 months part-time work to migrate fully to Rails4 - of that I'd say about 70-75% of the work was a combination of rewriting strong_parameters/attr_accessible stuff and updating/monkey patching Gems to get them working. But we did go really far, we removed all the stuff that generated deprecated warnings and removed all the "migration helper gems" like "protected_attributes". So if your project doesnt depend on many gems it could be really easy especially if you dont care about using the helper gems like protected_attributes until you get around to rewriting things.
- midas007 13y ago
  Part of the motivation why we adopted a lib/hacks/ convention Extracted here: https://github.com/steakknife/rails41rc_plus_hacks_and_threads https://github.com/steakknife/rails41rc_plus_hacks_and_threa...
awj 13y ago
It went comparatively smooth for us. 2 to 3 was a nightmare, 3 to 4 wasn't too awful. Some of the things that bit us: * Strong parameters means you're going to have to figure out what everything needs for params or break down and call permit! where acceptable. If anyone got crazy with attribute metaprogramming bullshittery, you're in for fun. * The deep_munge part of strong parameters has some strong opinions about how it should do its job. The code is there to prevent attacks where unusual user input is handed directly to ActiveRecord and interpreted by it. One special case to look out for is that it will rewrite a (JSON-supplied) empty array into nil, which makes life fun if your API happens to put some semantic meaning on nil vs. empty arrays. * The new restrictions on routing verbs are good stuff, but I can almost guarantee that something was getting away with using the wrong verb before. * XML parameter parsing has been extracted to a plugin. For some reason XML generation wasn't, but if people are sending you XML data you'll need this: https://github.com/rails/actionpack-xml_parser https://github.com/rails/actionpack-xml_parser That's all I can think of off the top of my head. In response to this: > Does that mean I need to go through and rewrite all our models and controllers before we can update? Not really, no. As a first step we rewrote all of our attr_accessible usage into model class-level constants we could run through strong_parameters. Eventually those moved out of the model, but it was good enough to get going. Example: # Rails 3.2 class Foo < ActiveRecord::Base attr_accessible :name, :bar, :whatever attr_accessible :name, :bar, :whatever, :approved, :as => :admin end # Rails 4.0 class Foo < ActiveRecord::Base UPDATEABLE_ATTRIBUTES = [:name, :bar, :whatever] ADMIN_UPDATEABLE_ATTRIBUTES = UPDATEABLE_ATTRIBUTES + [:approved] end
seancoleman 13y ago
I recently upgraded a 3.2 application to 4.0. At a high level, the necessary refactoring to make 4.0 work wasn't bad. It was upgrading gem dependencies, and sometimes switching out deprecated gems, that was a much bigger pain.

dkokelley 13y ago

I'm not 100% sure, but I believe you can upgrade without a lot of rewriting by using the protected_attributes gem (https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes).

kyleashipley 13y ago

3.2 -> 4 is an order of magnitude easier than 2 -> 3. The upgrade guide is pretty solid, and I imagine it mostly applies for Rails 4.1 as well: http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-3-2-to-rails-4-0 http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#u... I spent most of my time updating app config. For several of my 3.2 apps, I started using strong_parameters, so it wasn't a leap for me. Another app I have on 4.0 is using the https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes to retain the existing attr_accessible behavior until I get time to update. Hope that helps!

mountaineer 13y ago

I'm working on an update too, and am biting the bullet and rewriting the strong_parameters/attr_accessible parts. But, you can in theory use the Protected Attributes gem to aid migration with less rewrite.[1] [1] http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...

kule 13y ago

It's a way smoother upgrade - exactly as you mentioned really the only major change is from attr_accessible to strong parameters however you can still include the protected attributes gem for a quicker/easier upgrade path (https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes)

latortuga 13y ago

It does not, you can actually pull in a gem[1] to use attr_accessible just fine with Rails 4. If you want to transition to strong_parameters, you can include the gem in your Rails 3 project and begin migrating to it, though that's a tough sell on most Rails codebases I've seen as it requires you to update every action in your app. I have not personally migrated any of my code to Rails 4 from 3.2 yet but the transition will be far smoother than 2.3->3 was. [1] - https://github.com/rails/protected_attributes https://github.com/rails/protected_attributes

phereford 13y ago

You are correct that attr_accessible is gone in favor of strong parameters. Google fu yields http://stackoverflow.com/questions/17371334/how-is-attr-accessible-used-in-rails-4 http://stackoverflow.com/questions/17371334/how-is-attr-acce... Depending on how your test suite is set up (if you have one) there may need to be some sweeping changes there. When we migrated we had to switch from our should syntax to the expect s syntax. I can't remember anything else that was super crazy.

patrickdavey 13y ago

The railsdiff website is also a very handy little tool for quickly seeing the differences in config between versions: http://railsdiff.org/diff/v3.2.17/v4.1.0/ http://railsdiff.org/diff/v3.2.17/v4.1.0/

harrylove 13y ago
https://github.com/rails/rails/compare/v4.1.0...v3.2.17 https://github.com/rails/rails/compare/v4.1.0...v3.2.17
- timdorr 13y ago
  Railsdiff.org just shows you what's changed in the generated app files, not the actual libraries.

mbesto 13y ago

My co-founder wrote a book on exactly this. In case you're interested: https://leanpub.com/upgradetorails4 https://leanpub.com/upgradetorails4

jfaucett 13y ago

Also be wary of your projects Gems, we just finished a 3.2 to 4.0 upgrade and though rails itself was pretty easy, there were quite a few problems with things such as Solr, Formtastic plugins (some FormTag internals changed in rails4, which broke some stuff). So yea, the biggest problem was upgrading to Rails4 and getting the Gems to work- many of which had large structural changes in the Rails4 versions. For instance, Devise changed how they handle tokens in the Mailers, etc. We have a very large App and it took us about 2 months part-time work to migrate fully to Rails4 - of that I'd say about 70-75% of the work was a combination of rewriting strong_parameters/attr_accessible stuff and updating/monkey patching Gems to get them working. But we did go really far, we removed all the stuff that generated deprecated warnings and removed all the "migration helper gems" like "protected_attributes". So if your project doesnt depend on many gems it could be really easy especially if you dont care about using the helper gems like protected_attributes until you get around to rewriting things.

midas007 13y ago
Part of the motivation why we adopted a lib/hacks/ convention Extracted here: https://github.com/steakknife/rails41rc_plus_hacks_and_threads https://github.com/steakknife/rails41rc_plus_hacks_and_threa...

awj 13y ago

It went comparatively smooth for us. 2 to 3 was a nightmare, 3 to 4 wasn't too awful. Some of the things that bit us: * Strong parameters means you're going to have to figure out what everything needs for params or break down and call permit! where acceptable. If anyone got crazy with attribute metaprogramming bullshittery, you're in for fun. * The deep_munge part of strong parameters has some strong opinions about how it should do its job. The code is there to prevent attacks where unusual user input is handed directly to ActiveRecord and interpreted by it. One special case to look out for is that it will rewrite a (JSON-supplied) empty array into nil, which makes life fun if your API happens to put some semantic meaning on nil vs. empty arrays. * The new restrictions on routing verbs are good stuff, but I can almost guarantee that something was getting away with using the wrong verb before. * XML parameter parsing has been extracted to a plugin. For some reason XML generation wasn't, but if people are sending you XML data you'll need this: https://github.com/rails/actionpack-xml_parser https://github.com/rails/actionpack-xml_parser That's all I can think of off the top of my head. In response to this: > Does that mean I need to go through and rewrite all our models and controllers before we can update? Not really, no. As a first step we rewrote all of our attr_accessible usage into model class-level constants we could run through strong_parameters. Eventually those moved out of the model, but it was good enough to get going. Example: # Rails 3.2 class Foo < ActiveRecord::Base attr_accessible :name, :bar, :whatever attr_accessible :name, :bar, :whatever, :approved, :as => :admin end # Rails 4.0 class Foo < ActiveRecord::Base UPDATEABLE_ATTRIBUTES = [:name, :bar, :whatever] ADMIN_UPDATEABLE_ATTRIBUTES = UPDATEABLE_ATTRIBUTES + [:approved] end

seancoleman 13y ago

I recently upgraded a 3.2 application to 4.0. At a high level, the necessary refactoring to make 4.0 work wasn't bad. It was upgrading gem dependencies, and sometimes switching out deprecated gems, that was a much bigger pain.