I'm looking to upgrade my rails project from 1.8.7 to 1.9.2, but, when I swapped ruby versions in RVM, I had same issues getting the app started. (mostly with mysql (which... 64bit mysql on mac (any version) is a pain to set up, and almost impossible))...
But anyway, aside from mysql problems, is there anything I would need to change in my code that is no longer supported in 1.9.2?
There is way too many subtle changes to cover in something like SO, but this covers it quite well (I'm not involved in any way):
http://www.rubyinside.com/19walkthrough/
Assuming you're using fairly standard Ruby there shouldn't be anything which will cause problems, but I'm sure your tests will point out anything that needs fixing.
Related
Some background:
I am new to Ruby and Rails and I've been assigned to get an already completed Ruby on Rails project to compile from source.
The project has, as far as I've been able to discover, little to no documentation on how to set it up. The developers are unavailable for me to contact.
After doing some tutorials and learning the basics I have been trying to get the code to compile and run. My platform/setup is currently:
Windows 7
Ruby 1.9.3
Rails 3.2.13
Although I am attempting to develop with a VirtualBox Ubuntu setup alongside of this because I suspect it will be easier in the long run.
Despite there being no Gemfile for this project I have managed to (I believe) pin down and install all of the necessary gem packages (hopefully compatible versions). I am now running into this issue:
in alias_method': undefined methodpath' for class `ActionController::UploadedStringIO' (NameError)
As far as my searches have led me to believe this is a bug that can occur when the versions of Ruby and Rails are not correct/incompatible?
Is there a way to "reverse engineer" what version of Ruby and Rails was used to develop this project in the first place from the code alone? Could this bug be caused by me using 3.2.13 Rails if the original developers were using 1.8.7 Ruby? It seems to me that if I can emulate their setup closely enough then the source should compile and I can get down to business.
Additionally I am using the default WEBrick server. Is there a way to determine what the original team used for the web service? Does it even matter if they used a Apache setup or are these server implementations mostly interchangeable aside from efficiency?
Thank you for your time. If you have any further advice on how to handle this sort of project I'd love to hear that too.
If there is no Gemfile, it points to the Rails app being 2.3 or earlier. As for the Web server, they are interchangeable, but there is really very little chance that they were using Webrick, due to its ability (or lack thereof) to handle many concurrent requests. Chances are, they were using mongrel, or passenger via Apache or Nginx.
Since Rails 3.1 strongly recommends that it be installed with Ruby 1.9.2. But what about Ruby Enterprise Edition support? Ruby EE seems to be in the 1.8.x version, so I guess this means that future rails updates won't be working so well with it?
it's only a recommendation (and I suggest it too), because as you may know, 1.9.2 is the most recent version.
you can still use REE for your 3.1 rails app, but keep in mind that some day you'll be forced to switch to a newer ruby interpreter, and it's not a painless task (even if you have a decent test coverage).
if it's about a passenger matter, don't worry, it will work on 1.9.2 too ;)
if you generate new rails 3.1 app on 1.9 it will use new hash syntax, so you will not be able to easily switch to 1.8 later.
example: config/initializer/session_store.rb uses new hash syntax
YourApp::Application.config.session_store :cookie_store, key: '_yourapp_session'
Our large Rails 3.1 app runs very slowly when we migrated it to ruby 1.9.2
We upgraded it rather than creating from scratch, so maybe we did something wrong, but running it with 1.9 is so slow it's unusable, switching to REE make it run nicely again.
I decided to take the plunge and moved my app over to REE. It seems to work the same, a bitter faster in fact. The memory usage seems about the same. The guys from Phusion did an awesome job with the installer :)
Starting a new web app with Rails 3. I'm still relatively new to web development and have really enjoyed all the internet resources available to me while working in Ruby 1.8.7 and Rails 2.3.5. Any advice against using Ruby 1.9.2 on my new project?
I have been successfully converting all my Rails projects (except one, but I'm working on it) from Ruby 1.8.7/Rails 2.3.5 to Rails 3.0.0 and Ruby 1.8.7/1.9.2 RC2 and both environments are pretty stable.
Fortunately, things changed since I posted this question.
Rails
Unless you really have something that prevents you to do that, I strongly encourage you to start with Rails 3.
The effort required to upgrade an application from Rails 2 to Rails 3 should discourage you from starting from Rails 2.
Talking about plugins and Gems, many developers are starting to convert their libraries to Rails 3. Currently there's a very high level of compatibility.
Furthermore, Rails 3 focused plugins tends to be quite more powerful to the Rails 2.3 ones, thanks to the new Rails plugin API. They can load tasks, they no longer abuse monkey patching or rely on internal hacks.
Also, Rails 3 is just around the corner. Unless your project will be deployed in 1 week, the stable version will probably available before you deploy your code.
I this would not happe, consider that I'm currently managing a couple of Rails 3 project in a production environment and they are pretty stable (Rails 3 RC1, the Beta 4 has a really weird bug in the caching environment).
Ruby 1.9.2
Ruby 1.9.2 is way more powerful than Ruby 1.8.7. If this is a brand new project, I suggest you to use the 1.9 branch.
Usually, it's more easy to start a new project in Ruby 1.9 than converting an existing one.
Ruby 1.9.2 is faster, even more faster than REE. The most part of the common Ruby 1.8.7 Gems work with Ruby 1.9 except a few ones, such as RCov.
Again, it's very hard you're going to need a library which doesn't work with Ruby 1.9.2.
If it happens, chances are this is an outdated library and a better replacement is probably available in the Ruby ecosystem.
If you can't find an alternative, remember that Rails 3 provides an excellent way to use custom libraries, thanks to Bundler.
You can fork the project and ask Bundler to use your fork. You can even integrate the library in your repos and ask Bundler to load the library from a path.
Conclusion
From my personal experience, I've been very happy with Ruby 1.9.2 and Rails 3.
This is by far my favorite environment and my default environment for new projects.
If you can't use Ruby 1.9.2 try with Ruby 1.8.7.
On the other side, I strongly encourage you to start with Rails 3.
It ultimately depends on what the project is. If it is a personal project, and you are using it as a means to learn Ruby/Rails, than I think it would be worth learning and using the latest tools. If this is client work, or a project that your main goal is just to complete the thing, 2.3.5 / 1.8.7 would probably be the best choice, because of resources as you mentioned, and a lot of supporting libraries/gems will just work. You will have to learn Rails 3 / Ruby 1.9.x at some point because that's definitely where the community is headed.
I would do some research and see what gems you will need for your project, and make sure that everything is supported if you choose the Rails 3 / 1.9.2 route. Also, join the irc and ask around about other people's experience with whatever gems are in question.
I can tell you that I have a small Rails 3 / 1.9.2 application that runs just fine in production, although it is very small and a personal project.
You might want to try out Ruby 1.9.2 by using RVM
I've been using it off and on to develop some Rails3 apps while maintaining our current production sites (all the way down to Rails 2.2 / Ruby 1.8.5).
Only gripe being having to remember to start RVM up ^^
About half a year ago, when I started to learn Ruby and Rails, I first tried Ruby 1.9 but I soon gave up, because at that time nothing worked out of the box and almost every helping blog or tutorial was designed for Ruby 1.8.
What about now? (Dec 2009) Is it possible to get an existing Rails application running by a Ruby and Rails beginner without running into problems which can only be fixed by an absolute Ruby and Rails professional?
Unfortunately I dind't have good experiences with Ruby 1.9 and Rails.
You can read more here: Has anyone successfully deployed a Rails project with Ruby 1.9.1?
My opinion is that migrating an existing Rails app from Ruby 1.8.x to Ruby 1.9.1 is not as easy as you would think, event with an excellent test suite.
I'm also quite sure that most of the problems arise from trying to convert an existing application because you are working with an established code base.
Starting with a new Rails app with Ruby 1.9 should probably easier because you can trace a problem as soon as you write a single line of code so you can easily isolate which component is not compatible.
When migrating an existing app I had hard time trying to figure out which stack level was actually not compatible with Ruby 1.9. And there are more than one incompatible libraries at the same time I can't tell you how it's difficult to understand which one should be fixed first and which one originated the final error.
In 99.9% of the cases yes, there were rare cases where u might find problems but they should be solved with the new release.
As for the external gems and plugins, most of them now are fully compatible with ruby 1.9, however sepcial cases might exist but I'm not aware of any right now.
I will have to use JDBC with an old database, which I why I selected jRuby. If I get a book on ruby on rails that does not include jRuby information, will that be benficial to me?
Yes it will. Jruby is just another Ruby implementation, so pretty much everything that works in regular Ruby will work in Jruby as well. They have worked very hard at getting rails to run really well with Jruby While there are some gems that currently will not run in jruby, a Ruby On Rails book will definitely be relevant.
One thing to keep in mind though is you cannot run native (C code) gems with JRuby. However most of the popular ones have ports.