Ruby on Rails

Happy to say that the Ruby 1.8.7 RPM has been community vetted, is in rawhide, and is scheduled to go into Fedora 14. Many thanks to all those on ruby-sig for their efforts.

Attached are some updated Rails 2.3.8 srpms which address most of the issues that I could find when updating. They entail the rebased upstream sources and handle any discrepancies between the versions. With any luck these should be pretty close to being good to go and are ready for testing and the eventual push into Fedora.

activesupport, activerecord, actionpack, actionmailer, activeresource, rails

Have at it!

Before I get to rails, note that an updated Ruby 1.8.7 srpm is now available. The latest 1.8.7 release tarball is now being used (p299), there are many fixes and improvements, and its pretty close to the final version which will be pushed into Fedora (of course any and all feedback and additional improvements are more than welcome). Many thanks go out to Jim Meyering and Mamoru Tasaka for all their hard work and help to get to this point.

I'm also pleased to announce new Ruby on Rails rpms (built against Ruby 1.8.7) corresponding to the 2.3.8 and 3.0.0.beta4 Rails releases. Admittedly these will most likely require additional tweaking to resolve any issues as they are discovered, but what's there should be the complete Rails suite packaged and ready to deploy. Feedback for any / all of these packages would also be much appreciated.

Without further ado, here is the Rails 2.3.8 suite:
activesupport: srpm rpm
activerecord: srpm rpm
actionpack: srpm rpm
actionmailer: srpm rpm
activeresource: srpm rpm
rails: srpm rpm

And here is the the Rails 3.0.0.beta4 suite:
activesupport: srpm rpm
activerecord: srpm rpm
actionpack: srpm rpm
actionmailer: srpm rpm
activeresource: srpm rpm
rails: srpm rpm

Also note you will need an updated sqlite3-ruby rpm to build either set, which I provide here (rpm here).

Enjoy!

Just figure I'd share a few steps which are useful in getting a RoR application up and running on a web hosting provider. Obviously the steps will vary depending on your specific provider, but most should be the same assuming your given access to a home directory on the web server under which public_html resides.

• Install your rails app in a location _not_ under ~/public_html. For example ~/rails/appname would be a good place
• Run through your application specific install instructions, configuring db if necessary
• Link the 'public' directory under the rails root, to the public_html directory, eg
  

        ln -s ~/rails/appname/public ~/public_html/appname
   

• Edit .htaccess in the public directory, commenting out the following line and replacing it with:
  

        # AddHandler fastcgi-script .fcgi
        AddHandler fcgid-script .fcgi
   

  (at least I had to do this w/ my provider, I'm not sure how many this applies to)

• Add your gem path to ~/rails/appname/config/environment.rb like so:
  

        ENV['GEM_PATH']='/home/username/ruby/gems/gems:/usr/lib/ruby/gems/1.8/'
   

  
  Obviously your local and system wide gem paths will vary depending on your system. Use the 'gem environment' command to determine what they are.
• Finally you may also need to add the following to your ~/rails/appname/config/environment.rb:
  

         config.action_controller.related_url_root = '/appname'
   

  
  or if this doesn't work, add:
  

        ActionController::AbstractRequest.related_url_root = '/appname'
   

  This tells rails that our application is located under the '/appname' subdirectory of our webroot, eg in our case ~/public_html.

Though the process is pretty straightforward, since your not in control of the entire web server you may run into some tricky points as evident through the many related posts out there. Also your web application may have bugs of its own, further complicating the situation. Just stick to it and you should get it eventually.

So if you haven't noticed (eg if you're reading this via rss) I spent a while cleaning up and adding some useful features to this site. Unfortunately it took a little while to do so and involved some pain; you'd always hope that upgrading software and installing new plugins would be pretty simple and straightforward, but we all know how that goes.

I started this process looking for a good Ruby On Rails CMS webapp, as I'm far more familiar nowadays w/ Ruby and the Rails framework than I am w/ PHP. There are a few out there, including radiant and typo, but I don't feel like they currently meet my needs, and in addition I was having quite some trouble getting them up and running (especially Radiant; look out for a post in the very near future on installing Rails software on a webhost).

So I decided to stick w/ drupal for now. Changed the theme to a more configurable one. Indexed the site content & provided a search box (btw for those new to drupal, one can easily index your site content by navigating to http://sitelocation/cron.php, or setup a cron job to wget that url). Added a tag cloud (which required a hack that took a while to discover), code syntax highlighting support, and even a favicon (among other features).

I've also enabled anonymous comments again, having put in place various spam control measures.

As always if anything looks of or doesn't work, feel free to drop me an email and I'll look into it. And be sure to check back soon for new content!

[And for those drupal users who are still reading this far, a good tip to debug any module running on your system, without access to a debugger, is the use the 'watchdog' facility, that provides logger functionality. Results can be viewed in the Drupal admin reports interface which is populated from the Drupal db watchdog table].

Another caveat to look out for when using activerecord, especially for those of you who are using the nested set module and have optimistic locking turned on (which I'm guessing by the timestamp on that patch is making its ways to the Linux repos just about now).

It turns out when you go to destroy a model object in a nested set, it first updates the lft and rgt attributes before running the correct delete query against the db. eg

UPDATE "pools" SET lft = CASE WHEN lft > 13 THEN (lft - 2) ELSE lft END, rgt = CASE WHEN rgt > 13 THEN (rgt - 2 ELSE rgt END WHERE (1 = 1)
....
DELETE FROM "pools" WHERE "id" = 8 AND "lock_version" = 0
....

Unfortunately when optimistic locking is enabled (as it seems to be by default now), activerecord will detect the record has already been updated before it attempts to destroy it and will throw a "StaleObjectError" reporting "Attempted to delete a stale object". The object being used to perform the update, no longer reflects the current db state (granted it's only "lock_version", the db field used to perform lock checks, that is inconsistent, but that is enough to throw it off).

The only work around which I know of right now, save fixing ActiveRecord itself, is to use delete instead of destroy, which obviously is not optimal and doesn't work for all cases. I need to look into this issue some more myself, and will follow up with a better fix if I find it. Until then this also may help

Figure I'd pass on a bit of weirdness concerning Ruby's ActiveRecord. Apparently when two models class are associated via rails the association takes place through a custom ActiveRecord association class, eg if a host model has many instances of the nic model, host.nics will be an instance of ActiveRecord::Associations::AssociationProxy and _not_ a mere array of nics. AssociationProxy acts very similarily to an array, providing the expected functionality to get/set associated classes.

All of this is as expected, the weirdness arising from the fact a call to host.nics.class would return the 'Array' class and not 'AssociationProxy'. This is because AssociationProxy hijacks many methods and uses them for its own purposes, including the 'class' method.

To access an array from an instance of AssociationProxy, merely call the 'all' method, eg

host.nics.all.find { |nic| some_test }

Trying to call the 'find' method on nics directly will result in an ActiveRecord error: "Couldn't find Nic without an ID" as the AssociationProxy find method is called instead of the one you want.

Read this for more information.

This is well documented, but I keep running into the same issue and never learn from my mistakes. ;-)

When you invoke 'destroy' or 'destroy_all' on an ActiveRecord object, the ActiveRecord 'destruction' process is initiated, it analyzes the class you're deleting, it determines what it should do for dependencies, runs through validations, etc.

When you invoke 'delete' or 'delete_all' on an object, ActiveRecord merely tries to run the 'DELETE FROM tablename WHERE conditions' query against the db, performing no other ActiveRecord-level tasks.

This also holds true for the :dependent option passed into the ActiveRecord::Association methods (belongs_to, has_one, has_many, has_and_belongs_to_many)

Thus if you have a circular dependency between two model classes, and you want to delete both related records when one is deleted, one of the :dependent clauses _must_ be :destroy and the other :delete. if both are set to :destroy you'll have an infinite loop resulting in a "SystemStackError: stack level too deep" exception.

For example

class Person < ActiveRecord::Base
has_one :address, :dependent => :destroy
validate_presence_of :address
end

class Address < ActiveRecord::Base
belongs_to :person, :dependent => :delete
validates_presence_of :person
end

With this scenario, you are free to add a foreign key constraint to the person_id field of the addresses table and everything will still behave as expected. Best of luck.

I'm not sure if this was introduced in 2.3 or a prior version but today several of us working on the oVirt project discovered that Rails is now _requiring_ i18n localization translations for alot of stuff, namely the activerecord model validation errors.

Though i18n is a great feature, we have no time to write lots of translations right now, and we're still looking into how to turn this off (if even possible, I will update this post with the final solution when we find it).

IMHO the rails guys really shot themselves in the foot with this one. Even if it can be turned off, it shouldn't be turned on by default as its an extra feature than many people don't need and currently causes major breakage.

If you are a developer working on rails, make sure to look out for this when upgrading your rails instance (honestly I would wait, there seems to be many new 'features' causing issues and breakage).

</rant>

Rails in Fedora was upgraded to 2.3 in F11. When working on oVirt today, I discovered that changes to my templates were not being served to the user until I restarted mongrel/rails. Quickly searching around for the issue, I stumbled upon the Rails 2.3 changelog, particularly this section which states:

In most cases, you’ll want template caching to be turned on in production, which you can do by making a setting in your production.rb file:
config.action_view.cache_template_loading = true
This line will be generated for you by default in a new Rails 2.3 application.

While this is an excellent default for production systems, for development this is undesired (eg you'll need to restart mongrel every time you make a template change no matter how small), and thus adding the following to config/environment.rb resolves the issue (preferably you'll just enable in in your dev environment, but I didn't really care as this is on my dev box)

config.action_view.cache_template_loading = false