Entries from September 2008 ↓

Rails’ find_by_sql is the devil. Ninety nine percent of the time find_by_sql is unnecessary and problematic, but it’s sooo seductive. I can’t even begin to count the ways that find_by_sql can cause trouble, but here’s a few:

• Plugins like acts_as_paranoid rely on developers *not* using the back door to get around the dynamic conditions to exclude deleted rows.
• There quite a few gotchas, ie: “SELECT * FROM users JOIN another_table …” won’t work because ActiveRecord will use the last ID field, not the first.
• Logic “hidden” in find_by_sql is not reusable (as compared to a fancy association, etc)
• It offends my aesthetic sense. We all like to pretend our ORM layer isn’t leaky.. don’t we?

I remember a time when we had to use find_by_sql when we found a feature was missing from ActiveRecord. I propose that the only remaining legitimate use of ActiveRecord may be to call a stored procedure.

So, keeping with the hyperactivity theme, I suggest that we all take some ActiveRitalin: A plugin for Rails that tells ActiveRecord to chill out, and causes developers to sit and think a bit before proceeding.

ActiveRitalin makes find_by_sql private and introduces find_by_sql_with_excuse that warns upon each use. The implementation is very simple:

module ActiveRitalin
  def self.append_features(klass)
    super

    klass.class_eval %(
      def self.find_by_sql_with_excuse(excuse, sql)
        RAILS_DEFAULT_LOGGER.warn("Find By Sql called with excuse: " + excuse )
        find_by_sql(sql)
      end

      class << self
        private :find_by_sql
      end
    )
  end
end

To use, from your rails application’s root dir:

script/plugin install git://github.com/lukegalea/activeritalin.git

Think you need find_by_sql? Ask yourself the following questions:

• Can I just use :include, :select, :join, :conditions or some combination of the above?
• Should this be an association? (perhaps with :conditions and :select on it? Maybe :readonly?)

Rails’ ActiveSupport package includes an inflector class. This lets you do things like singularize and pluralize strings, camel case text, etc.

I’m building a framework that lets Rails developers use erlang + mnesia to replace their ruby models and traditional relational DBs (using Hyperactive Resource + Mochiweb). But a key part of interoperating with rails is being able to infer that “Person” is the singular for “People”.

Inflector.erl brings this magic to erlang! Witness the awesome power:

1> inflector:singularize(”mice“).
“mouse“
2> inflector:titleize(”i_love_erlang“).
“I Love Erlang“
3> inflector:ordinalize(142).
“142nd“
5> inflector:pluralize(”quiz“).
“quizzes“
7> inflector:tableize(”MyModelModule“).
“my_model_modules“

Inflector.erl includes functions for pluralizing, singularizing, camelizing, titleizing,
capitalizing, humanizing, underscoring, dasherizing, tableizing, moduleizing,
foreign_key..isizing? and ordinalizing!

I found it very difficult to implement some functions without regular expressions, so it does require R12B4 of erlang due to the vastly improved regular expression support B4 offers. The majority of the inflections are just standard pattern matching and list manipulation, though.

It also has an eunit test suite embedded, so it requires eunit to compile.. But everyone has eunit, right?

Also, in order to minimize the impact of compiling the regular expressions, Inflector.erl caches all compiled regular expressions.. so I expect performance won’t be a problem but be aware that it does register a process named “re_cache”.

Download and enjoy!! Or via github ( git://github.com/lukegalea/inflector.git )