script/plugin install git://github.com/zdennis/ar-extensions.git
gem install ar-extensions

While the original functionality of database agnostic ar-extensions is to import (bulk insert) many records quickly, my favorite new features for 0.9.1 are the new find and save options which allow developers to quickly customize queries without writing SQL for the MySQL database.

Find

For instance, suppose the wrong index is used to perform your favorite query. This use to mean that the developer had to dig through the logs, find the generated query, and rewrite the entire query with the correct index in SQL and execute it with ActiveRecord::Base.find_by_sql. With ar-extensions, its just another parameter to the find method. Similarly, leveraging MySQL functionality such as SQL_CACHE, HIGH PRIORITY, and LOCK IN SHARED MODE is just as easy.

Beer.find :all, :index_hint => 'USE INDEX (uk_beer_name)'
#SQL: SELECT * from `beers` USE INDEX (uk_beer_name)

Beer.find :all, :keywords => ' SQL_CACHE HIGH_PRIORITY'
#SQL: SELECT SQL_CACHE HIGH_PRIORITY * from `beers`  

Beer.find :all, :post_sql => ' FOR UPDATE', :pre_sql => '/* My little comment*/'
#SQL: /* My little comment*/ SELECT * from `beers` FOR UPDATE 

Finder SQL Exposed

And if that’s not enough to take advantage of MySQL query options, finder_sql_to_string will send the query string back and you can gsub your heart out before execution. It’s also a great to use for debugging purposes.

sql = Beer.send :finder_sql_to_string, :conditions => ['flavor like ?', 'delicious']
Beer.find_by_sql sql.gsub('WHERE', 'where /* I heart lowercase */')

Save and Create

As for save and create, the new options provide more control over database inserts and updates, especially when unique keys are involved.

Animal.create!({:name => 'Jerry Giraffe'},   n_duplicate_key_update => [:password])
#INSERT INTO animals (`name`, `fav_beer`, `password`) VALUES('Jerry Giraffe', 'Pabst', NULL) ON DUPLICATE KEY UPDATE `animals`.`password`=VALUES(`password`)

animal.save(:keywords => 'LOW_PRIORITY', :ignore => true,
            :pre_sql => "/* Now I know where this query is coming from within my Rails code!*/")
#/* Now I know where this query is coming from within my Rails code!*/ UPDATE LOW_PRIORITY IGNORE `animals` SET `fav_beer` = 'Pabst', `password` = 'frenchfry', `name` = 'Party Giraffe' WHERE `id` = 1

In addition to these spiffy new features, ar-extensions provides support for all of these:

• (new) create and save options rdoc
• (new) find options rdoc
• (new) insert_select from one table to another rdoc
• (new) find and count unions rdoc
• (new) delete options rdoc
• import (bulk insert) with synchronization rdoc
• csv export rdoc
• better finder hash support rdoc
• disabling foreign keys rdoc
• fulltext search support rdoc
• temporary table manipulation rdoc

That’s a lot of rope! If you do by chance hang yourself, please send bugs, comments and even patches to the new github issue tracker.

Every blog post could use a finger monkey

The vanilla rails ActiveRecord finders do not allow us to specify the :select clause when associations are eager loaded with the :include option. There has been ticket after ticket on the rails site the proposed  patches were rejected on the grounds that an alternative, such as ActiveRecordContext (a fantasic plugin by the way) should be used instead.
From the database perspective, selecting fewer columns can give  huge performance boosts in some situations especially when the selected fields are indexed. However, often when joined tables are sparse (many base table records are pointing to the same joined table records), you might be better off running two queries: one on the base table, followed by a second on the join table with the collected foreign keys. To illustrate this, an employee has a fairly unique address while she shares her position in the company with several others.

Employee.find :all, :include => :position

would probably be less efficient than

employees = Employee.find :all

positions = Positions.find :all, :conditions => ['id in (?)', employees.collect(&:id)]

employees.each{|employee| employee.position = positions.select {|p| p.to_param == employee.posistion_id}

This is exactly what active record context does but without the messy details. In addition, the records are cached so any subsequent references to the associations hit the cache instead of rerunning a query.

employees = Employee.find :all
Positions.preload(employees)

On the other hand, provided that a reasonable number of records are queried, including the address would probably be more efficient.

Employee.find :all, :include => :address, :select => 'addresses.city, employees.*'

In this case wouldn’t it be great to use a :select clause if for instance you were only interested in for instance the city. To achieve this, I updated the eload select plugin. It does use some tricky parsing but does have the advantage of accepting aliases and allowing you to select from the base table (some alternates include all base columns).

One disadvantage of using :select is a lot of overhead is spent in rails on aliasing columns. Its really nasty in there and probably the reason that :select is not supported with :include out of the box.

If you really are having performance issues, its probably best to abandon the :include altogether and rewrite it as a :join.

employees = Employee.find :all, :select => 'addresses.city as address_city, employees.*',

:joins => 'left outer join addresses on addresses.id = employees.address_id'

employees.first['address_city']

Stefan Kaes has written an excellent plugin called piggy back that does this for you with belongs_to and has_one relationships. For common delegated fields, this plugin is a winner.

Employees.find :all, :piggy => 'address_city'

employees.first.address_city

So in conclusion, install eload-select plugin and you get :select and :include playing happily together. However, sometimes its not the best option out there. There is a huge open source toolbox. Use them wisely.

eload-select plugin to the rescue!

Employee.find :all, :select => 'addresses.city, address.state, employees.*',
                    :include => :address

The advantages of the eload-select plugin:

1. Works with aliases and database functions

Employee.find :first,
  :select => 'now() as current_time, addresses.city, DATE(addresses.created_at) as addresses.created_at, employee.*'
  :include => :address

2. Plays nice with other plugins like ar-extensions
3. Selects columns on the base table (some options force you to select all of the base table)

Employee.find :all, :select => 'addresses.city, employees.name, employees.start_date',
                    :include => :address

script/plugin install git://github.com/blythedunham/eload-select.git

And your off! Recently updated to work with all versions of rails including 2.3.

playing pinball in Vegas reminded me of mongrel multi caching funtime

We really like cache with our rails at Spongecell and have been really successful with Tom Fake’s Action Cache plugin when we are unable to page cache highly demanded content.

One little concurrency issue that I encountered running with the Action cache plugin on multiple mongrels was one mongrel would delete (expire) a meta data file while another was simultaneously writing the meta or data file. Anyhoo, the result was an angry corrupt file that was served to other web clients. This made some of customers angry. Then I was angry. To avoid all the hatred, I patched the method cached_entry in action_cache.rb with this little change to remove the cache on exceptions. action_cache.diff

        rescue
          remove_cache_item(controller)
          return nil
        end

With that said, here are my favorite features which you will love too!

• The timer expiry. So… you can be super lazy and just expire your cache say every 10 minutes without having to write complex sweeping code that may or may not slow down some other actions.
  @response.time_to_live = 10.minutes

• Easy integration with  Nginx X-Accel-Redirect (and Apache’s X-SendFile) to tell your web server to send the cached file downstream. This allows you to still use before and after filters, but  offloads the work the Nginx and free up your mongrels a bit to bark at someone else.

For more information on rails caching, check out Gregg from Rail Envy’s sweet post.