Myron Marston has done a stellar job shepherding it through the Rails 3 transition, but he’s busy with other awesome projects now and has asked me to look for a new maintainer. So: If you’re interested in helping keep NullDB up to date with the latest changes to ActiveRecord, please get in touch!

Sock.build_fuzzy # => #<Sock type: "fuzzy" id: nil drawer_id: nil>
sock_drawer.socks.build_fuzzy # => #<Sock type: "fuzzy" id: nil drawer_id: 123>

At first we might think to put it in an a collection extension module:

class Sock < ActiveRecord::Base
  module SockCollectionHelpers
    def build_fuzzy
      build(type: "fuzzy")
    end
  end
  # ...
end

Now we have to remember to add it to every Sock association:

class Drawer < ActiveRecord::Base
  has_many :socks, extend: Sock::SockCollectionHelpers
  # ...
end

And we also need to include it in Sock:

class Sock < ActiveRecord::Base
  # ...
  extend SockCollectionHelpers
end

…but this doesn’t work:

sock_drawer.socks.build_fuzzy # => #<Sock type: "fuzzy" id: nil drawer_id: 123>
Sock.build_fuzzy # => Raises no method exception for Sock.build()

And anyway, we want this to be available globally without explicitly extending associations.

Next, we try adding a class method to the Sock class. Since ActiveRecord association proxies delegate missing methods to the assoication class, it seems like this should work.

class Sock < ActiveRecord::Base
  def self.build_fuzzy
    build(type: "fuzzy")
  end
  # ...
end

This is a complete failure. While the association does forward the .build_fuzzy call to Sock, once in the call it is operating in the context of the class object, which as we saw before has no #build method.

sock_drawer.socks.build_fuzzy # Raises no method exception for Sock.build()
Sock.build_fuzzy # => Raises no method exception for Sock.build()

However, a slight change makes everything work as hoped:

class Sock < ActiveRecord::Base
  def self.build_fuzzy
    scoped.build(type: "fuzzy")
  end
end

Now when we call #build_fuzzy on the class it builds a fuzzy sock unassociated with any drawer, and when we call it on an association it builds a fuzzy sock with the appropriate drawer ID set:

Sock.build_fuzzy # => #<Sock type: "fuzzy" id: nil drawer_id: nil>
sock_drawer.socks.build_fuzzy # => #<Sock type: "fuzzy" id: nil drawer_id: 123>

All this thanks to the #scoped method, which is aware of the current scope.

Thank you to Dan Kubb for figuring this out for me.

UPDATE: Fixed def build_fuzzy to be def self.build_fuzzy in the last two examples.

require 'active_record'

class Greeting < ActiveRecord::Base
  establish_connection(adapter:  'mysql', 
                       database: 'scratch', 
                       password: ENV['MYSQL_PASSWORD'])

  connection.create_table(:greetings) do |t|
    t.string :text, limit: 10
  end
end

g = Greeting.create(text: "Greetings and salutations, esteemed world!")
g.reload
puts g.text # => "Greetings "

This is potentially surprising to users. To improve usability, we can set a validation:

require 'active_record'

class Greeting < ActiveRecord::Base
  validates :text, length: { maximum: 10 }
end

g = Greeting.create(text: "Greetings and salutations, esteemed world!")
g.valid? # => false
g.errors.full_messages # => ["Text is too long (maximum is 10 characters)"]

Now we have a new problem: duplication of the length cap. The number “10″ now appears in both the database migrations, and the model validations.

We could extract it out into a constant, although referencing models can be problematic in migrations. But that still doesn’t account for the (many) cases where we don’t specify an explicit field limit in the migration, and instead rely on the built-in ActiveRecord defaults for field limits.

Here’s a solution that uses database reflection to validate a field is within its DB column size limit:

validates :text,
          :length => {
              :maximum => columns_hash['text'].limit
          },

ActiveRecord provides the columns_hash to get at column metadata gathered from the database backend. In the code above we query it for the limit attribute, and use that as the max field length. By pulling the limit from the DB, we avoid duplication of knowledge.

Projects using Ruby on Rails often lack strong distinctions in two main areas:

• The model/record conflation: Seeing “models” as strictly DB-backed resources.
• The view/template conflation: failing to draw a line between view objects and HTML templates.

The conflations are encouraged by Rails’ design decisions. When choosing which enterprise design patterns to translate into code, the Rails developers chose Active Record (a relatively thin, one-to-one take on the ORM idea), and Template View.

I am not faulting them for this decision. These were both thoroughly pragmatic decisions which mapped well to the kind of applications that Rails was aimed at. By encoding these opinions into the framework and covering them with a sweet coating of convention-over-configuration, Rails saved thousands of projects from pattern analysis paralysis.

But now Rails applications are maturing, and a lot of developers are starting to realize that these patterns may not scale so well to more and more complex applications.  When figuring out how to move forward, we could do much worse than to consult the same book that laid the blueprints for Rails’ architecture, Patterns of Enterprise Application Architecture.

Here’s Martin Fowler on Domain Models:

An OO domain model will often look similar to a database model, yet it will still have a lot of differences. A Domain Model mingles data and process, has multivalued attributes and a complex web of associations, and uses inheritance.

As a result I see two styles of Domain Model in the field. A simple Domain Model looks very much like the database design with mostly one domain object for each database table. A rich Domain Model can look different from the database design, with inheritance, strategies, and other [Gang of Four] patterns, and complex webs of interconnected objects. A rich Domain Model is better for more complex logic, but is harder to map to the database. A simple Domain Model can use Active Record, whereas a rich Domain Model requires Data Mapper.

Note that Fowler is referring to the Active Record and Data Mapper design patterns, not to the Ruby libraries those patterns inspired. There is a correspondence, though: the DataMapper library, like the pattern it is based on, puts a higher value on decoupling the domain model from the database schema.

Now on to views. Here’s Fowler talking about Two Step Views, an alternative to the Template View pattern:

You may… want to want to make global changes to the appearance of the site easily, but common approaches using Template View or Transform View make this difficult because presentation decisions are often duplicated across multiple pages or transform modules. A global change can force you to change several files.

Two Step View deals with this problem by splitting the transformation into two stages. The first transforms the model data into a logical presentation without any special formatting; the second converts that logical presentation with the actual formatting needed.

I do a lot of two-step view processing in my projects. I haven’t had a chance to take a close look at, but I think this process is also what Jeff Casimir is aiming at with Draper, and I support and applaud his efforts.

And that’s all I had to say about that… I just wanted to post those quotes in case anyone else found them noteworthy.

require 'rubygems'
require 'active_record'

ActiveRecord::Base.establish_connection(
  :adapter => "sqlite3",
  :database => ":memory:")

ActiveRecord::Base.connection.create_table(:monsters) do |t|
  t.string :name
end

class Monster < ActiveRecord::Base
end

cm = Monster.create(:name => "Cookie Monster")

For little one-off demo scripts that seems a bit excessive to me. For comparison, here’s the equivalent DataMapper:

require 'rubygems'
require 'datamapper'

class Monster
  include DataMapper::Resource

  property :name, String, :key => true
end

DataMapper.setup(:default, 'sqlite::memory:')
DataMapper.auto_migrate!

cm = Monster.create(:name => "Cookie Monster")

Can anyone golf the ActiveRecord down any smaller?

EDIT: Thanks to Jacob Rothstein for this version:

require 'active_record'

class Monster < ActiveRecord::Base
  establish_connection :adapter  => 'sqlite3',
                       :database => ':memory:'

  connection.create_table( :monsters ) { |t| t.string :name }

  cm = create :name => 'cookie monster'
end

NullDB network on Github

I love Open Source. NullDB, a weekend hack that I barely touched after its first version, continues to attract periodic forks and patches. For a long time I’ve been meaning to sit down and roll in all the contributions that people have made over the last couple of years.

But I realized something yesterday. I haven’t used ActiveRecord for anything serious for around a year. And I can’t imagine choosing to use ActiveRecord for any projects in the future, because I literally can’t think of a single scenario in which AR is a better choice than DataMapper. (Just as an example of DataMapper’s awesomeness: it turns out NullDB isn’t even needed for DataMapper, because you get it for free).

There isn’t a foreseeable future in which I’ll be using NullDB regularly, and if I’m not using it it’s never going to be a priority for me. Which, realistically, means it’s never going to have my attention.

I think the time has come to turn NullDB over to a new maintainer, someone who has a more active interest in testing ActiveRecord-based codebases. The ideal candidate would:

1. Be using NullDB on a daily basis.
2. Have submitted at least one tested NullDB patch.
3. Be committed to the NullDB philosophy of preferring public APIs to fragile monkeypatching.

If you think this describes you and you are interested in becoming the NullDB maintainer, please get in touch.

Here’s the text of the README:

What

NullDB is a Rails database connection adapter that interprets common database operations as no-ops. It is the Null Object pattern as applied to database adapters.

How

Once installed, NullDB can be used much like any other ActiveRecord database adapter:

  ActiveRecord::Base.establish_connection :adapter => nulldb

NullDB needs to know where you keep your schema file in order to reflect table metadata. By default it looks in RAILS_ROOT/db/schema.rb. You can override that by setting the schema option:

  ActiveRecord::Base.establish_connection :adapter => nulldb,

                                          :schema  => foo/myschema.rb

There is a helper method included for configuring RSpec sessions to use NullDB. Just put the following in your spec/spec_helper.rb:

  Spec::Runner.configure do |config|

    ::NullDB.insinuate_into_spec(config)

  end

You can also experiment with putting NullDB in your database.yml:

  unit_test:

    adapter: nulldb

However, due to the way Rails hard-codes specific database adapters into its standard Rake tasks, you may find that this generates unexpected and difficult-to-debug behavior. Workarounds for this are under development.

Why

NullDB is intended to assist in writing fast database-independant unit tests for ActiveRecord classes. For why you would want to test your models without the database, see: www.dcmanges.com/blog/rails-unit-record-test-without-the-database.

NullDB was inspired by the ARBS and UnitRecord libraries. It differs from them in a couple of ways:

1. It works. At the time of writing both ARBS and UnitRecord were not working for me out of the box with Rails 2.0.
2. It avoids monkey-patching as much as possible. Rather than re-wiring the secret inner workings of ActiveRecord (and thus being tightly coupled to those inner workings), NullDB implements the same [semi-]well-documented public interface that the other standard database adapters, like MySQL and SQLServer, implement.
3. UnitRecord takes the approach of eliminating database interaction in tests by turning almost every database interaction into an exception. NullDB recognizes that ActiveRecord objects typically can‘t take two steps without consulting the database, so instead it turns database interactions into no-ops.

One concrete advantage of this null-object pattern design is that it is possible with NullDB to test after_save hooks. With NullDB, you can call +save+ and all of the usual callbacks will be called – but nothing will be saved.

Limitations

• It is not an in-memory database. Finds will not work. Neither will reload, currently.
• It has only the most rudimentery schema/migration support. Complex migrations will probably break it.
• Lots of other things probably don‘t work. Patches welcome!

Who

NullDB was written by Avdi Grimm <avdi@avdi.org>

Where

• Homepage: avdi.org/projects/nulldb/
• Public SVN: svn.avdi.org/nulldb/