Our application is still on 2.x and we were delaying migrating in hopes that we would have time to actually just refactor into a 3.x application. So this effectively means that we are going to either need to fast track this effort which is likely not going to happen, or make the attempt to migrate to 3.x with an application the size of an elephant.
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`.
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.
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)?
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.
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)
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.
CarrierWave appears to support Rails 4; the rest are not doing anything special other than making jquery js acripts available in the asset pipline without manually installing them, so shouldn't cause any issues.
You'll have a bit of work to do to migrate to strong parameters, but you can always add the protected_attributes gem back to re-enable support for attr_accessible.
I'd suggest checking out the Rails 4 migration RailsCast.
As an aside, how is the jquery-fileupload thing? I was reading about it, and when I saw there was some weird iframe thing for IE... I closed the page and walked away. That kind of thing looks like it could be a nightmare if something goes wrong.
> As an aside, how is the jquery-fileupload thing?
I don't have a good answer: Fine to program with, but certainly took some doing for our particular need. (We had a number of requirements that made the "easy" out-of-the-box jquery-fileupload not suitable.)
Ask me in a couple of months and I'll probably have a lot of opinions to give.
> and when I saw there was some weird iframe thing for IE... I closed the page and walked away.
We are migrating customers from a C++ desktop app to a web interface: So anyone on old IE with problems will be informed that they're not supported on the new system, so keep using the old and let us know after they upgrade. :) (Newer IE is OK.)
Deviously, this also prevents absolutely everyone from ditching the old app and swamping the new system on day 1.
This would in many ways seem to suggest a less urgent need to upgrade from 3 to 4 than there was from 2 to 3 though. It seems like a major focus of 4 was speeding up client/server interactions. If that's not a major concern, I don't necessarily think it's something to lose sleep over in the near term.
I'm in the same boat (having been building on Rails 3 for a good while) and for now I'm going to stay put. People who are more knowledgeable about the specific updates please correct me if my assumptions are off-base.
