I have a small rails app, which was running fine with Ruby 1.8x and Rails
2.x. In a regrettable decision, I decided to move to Ruby 1.9.x and Rails 3,
and it's a glorious pain.
My Ruby app uses MySQL, and I use Active Record for that.
However there is an earlier pgm I had written to fill in the database
before I did Rails (2.x), which is part of the complete application now.
(I can test/run the standalone pgm outside Rails and there is no
problem.)
This standalone program is using MySQL and dbi gems. I call this program as such from a model:
system("ruby standalonepgm.rb -args ")
In Rails 2.0 this works without any issues.
In 3.0 the program exits without any way to capture the error.
Running under console I see that the program dies because it can't find the
dbi gem!
If I put the dbi gem in the Gemfile and do bundle date, then there is
real trouble. Rails refuses to start - the rails server dies with all kind of issues.
I can put in the screendump, but I think that's unimportant.
There seem to be 2 issues:
DBI is surely incompatible with the gods of Rails
Rails creates a sandbox, and all programs called must live in that
sandbox (that's why just a require statement doesn't suffice .. it has to be in Gemfile).
Is it fixable or I am one of those who got bitten by the hidden black magic of rails, and my past 8+ weeks of effort is down the tubes?
It's fixed by using
Bundle.with_clean_env do
system("ruby pgm.rb"
end
I had never read bundle doc ..this case is described in it ..
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.
I'm newish to rails, and I started with rails 3 and ruby 1.8.7
I'm not sure exactly why I went with 1.8.7, but I think it was because many gems are not supported with 1.9.
Was my analysis wrong and I can move to 1.9?
What are things to consider moving to 1.9? Is rails 3 ready for it?
I've moved to 1.9.2 about two months ago and so far everything seems OK. 1.9 is largely backwards-compatible so most things are not a problem.
That said there are two possible sources of significant annoyance when going to 1.9:
CSV parsing. Ruby switched internally to FasterCSV but doing require 'fastercsv' will result in an error. This will require changes to your code if you are doing any CSV parsing.
Encoding changes. If your code (not data) includes non-ascii characters your app will fall apart. The fix is not hard, you have to put the magic comment # encoding: utf-8 on top of any such files, but again a possible source of pain.
All gems I've been using work fine (except those doing CSV).
The only real way to find out for your application is to use rvm and install 1.9.2. Upgrade all of your gems using Bundler and then run all of your tests. Manual testing of the application will ferret out any remaining issues that are not common and specific to your code and data.
I have a old app made on rails 1.2.5, this application have alot of access per day.
I intend to upgrade my server (a joyent accelerator) to run ruby 1.9.x and work with rails 3 but I can't stop or move this app to another server.
Have any way to run this application on ruby 1.9?
or run two ruby versions (1.8.7 and 1.9) at the same time?
or on the last case upgrade my app to work with rails 3?
Thanks.
There was quite a few patches to Rails to make it run under Ruby 1.9. I think you are up for a challenge if you try to do that. With Ruby Version Manager you can work with multiple ruby environments from interpreters to sets of gems.
Does it have to be switched over to Rails3 and Ruby 1.9?
Can you just throw you old app on a virtualized server and keep the app running as is?
The reason for my suggestion is that we just went through a similar case. A local business (a construction association) had a pair of apps developed for them 2-3 years ago (works with Rails 1.2.6). Nothing overly major (a billing app, and a bid/contractor/customer management system). Everything works, so no need to update anything.
Their hosting provider was not willing to keep an old outdated rails available in shared hosting environment. Hosting shop cited maintenance can't be streamlined, security concerns, etc. Sure enough, the same host offers to rewrite the apps for current technologies (for a price, of course).
Client wasn't happy with them. The shop that developed the apps since closed and the developers left for greener pastures. But everything works, so why reinvent the wheel, right? Client went looking for alternatives. Came to us. We sat down with the client, did some cost/benefit analysis and decided to just host in a virtualized environment (at another provider). Did that in a week (with some hick-ups): back-up, move, restore, test, everything works. And it's been working now for 3 months without any issues.
This might not work for you, but unless you need to add to the app why fix what ain't broken?
Rails 3 works with Ruby 1.8.7
Another option (apart from obvious RVM) is to leave your Ruby 1.8.7 and Rails 1.x as is and install latest JRuby and Rails 3.0 and dependent gems with jruby -S gem install rails. Ruby and JRuby gems perfectly coexist without any interference. OpenSolaris in Joyent's Accelerator is good at running Java, so you won't have much problems with it.
P.S. Btw, I won't recommend updating your Rails 1.x app to 3.x, unless you're planning to add lots of new features to it. It can be very painful, especially if you used lots of old-school gems and plugins.
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.