Building an ActiveRecord condition parameter can result in a lot of unattractive code if it needs to depend on various things. E.g. if you need to find records that match multiple criteria given by the user, you might end up writing a lot of code to do so.

Using a hash as a condition might work in some cases:

1 conditions = {}
2 conditions[:orderno] = orderno unless orderno.blank?
3 conditions[:color] = color unless color.blank?
4 ...
5 Product.find(:all, :conditions => conditions)

However this only works for simple searches (where values are matched by equality). If you try to build a slightly more complex condition (like searching for a substring in the name of a product, or for products that are cheaper than a given price), a hash won’t work and you need to use an array for the condition. This usually leads to clumsy code that needs to assemble the query string and its parameters in the right order depending on the given criteria. However, by extending the Array class with a helper method, everything becomes easier and nicer:

Ruby on Rails 2.1 is almost here and there are several interesting features coming with it. Among many little details, performance optimizations and some bug fixes, my favorites are:

• ActiveRecord named scopes
• ActiveRecord dirty field checking and partial updates
• Built-in gem dependencies

Trying to paginate special queries gave me a headache for quite some time. As summarized in one of my previous blog posts “Paginating special queries”, custom finder methods do not work without problems if you use the will_paginate plugin.

There are several plugins that make life easier when you need custom finder methods to do special queries in your models. Widely known are scope_out and scoped_proxy. Both of them are great plugins with different features, but unfortunately neither of them work out of the box with pagination.

Some days ago, Nick of Pivotal Blabs brought back to my mind, that there’s another plugin called HasFinder. HasFinder basically works like scope_out and scoped_proxy and combines advantages of both plugins. Besides the basic idea to define different scopes for an ActiveRecord model, you can also access methods (finder) in nested scopes that exactly behave like ActiveRecord associations do. Additionally, HasFinder works out of the box with will_paginate.

Head over to Nick’s HasFinder article to find out more about it. HasFinder is available as a gem or can be installed as a plugin from SVN. Great plugin, Nick.

Update 2008-04-02: HasFinder functionality will be included in Rails 2.1, called named_scope

Did you ever want to create multiple models in one action? E.g. if your user model has many email addresses, create a user record and his first email address when he signs up… Nick of Pivotal Blabs wrote a nice article about it – but it almost drove me to despair this morning when I was trying to break it down to my user and email addresses model.

ActiveRecord does not natively suppport column types of ENUM or SET. If you want an attribute to act like an ENUM, you’ll most probably use a string and restrict it to certain values using validates_inclusion_of. However, once you’ve got used to Ruby, you’d probably prefer to have symbols as values for these attributes. Here’s a small and easy-to-use snippet that can be used to symbolize values of any ActiveRecord attribute.

I suppose, you know the great scope_out plugin for rails. If not, go check it out, since it’s really great to define DRY scoped associations. Basically, you can use scope_out to define the scoped associations within the model the scope is applied to. However, what I’m missing is a feature like a default scope that can be applied to the model and scopes the default finder.

The will_paginate plugin for Rails is one of the best pagination plugins I know of and I like the ease of using it. Instead of using Model.find, simply use Model.paginate(:page => x) and you’ll get back a collection that behaves like an array and can be displayed in views like any other collection. Additionally the returned collection has some new methods (like page_count and total_pages), which are useful to display pagination links. Installing the will_paginate plugin adds the pagination class method to all models; it even works with automatic finders: e.g. you can use Model.paginate_by_attr, which will paginate queries for Model.find_by_attr.

However, pagination can become tricky if you want to paginate collections returned by special queries…