Agility is not solely found in practices. Developers may implement stories, you may practice continuous integration, pair, practice TDD, DDD, <Any>DD - just because you do doesn’t make you Agile.

Actually I’m going to go out on a limb here with this: ‘Most organizations who believe they are Agile are actually far from it.’

The big thing that’s missing: Authority. Teams are often hamstrung by politics and power struggles preventing them from autonomous control over their practices and processes.

Another thing that’s often missing: Courage. The courage to try something for an iteration and learn from it. If a suggestion has merit why fear the consequences when engrained in your pschye is rapid feedback allowing you to try and try again? With rapid feedback teams should be thinking more of opportunity than consequence.

Can your team respond to change? Can you respond to the opportunity to improve by tweaking processes and practices? You may have the intellectual capability, but do you have the authority?

Putting lipstick on a pig doesn’t make it catwalk material.

Taking the authority to tweak processes for solving a problem away from the problem solvers is an excellent technique for building resistence and disenchantment. By doing this within a short period of time an organization will have guaranteed capability to hit the drink market with a new explosive product: ‘Bottled Frustration’.

The teams methodology will start conforming to that of the dictatorship imposed on them. Sure, the team can build Firewalls and Anti-Corruption Layers but the best they’ll do is practice ‘Agile in a Bubble’ - a virtual world detached from the reality of the organization.

In these environments the big challenge is to establish Trust with those imposing resistence. Building up a record of excellent delivery is great, but that’s little comfort when you’re the team trying to build that track record.

For mind in these cases your ability to justify your teams beliefs, practices and processes is invaluable. I’m surprised how few people appreciate the fundamentals of what they do and why they do it - if you lack the ability to defend what it is you do you are nothing short of a pawn in game played by others. So, knowledge and logic is one part of the justification effort - that’s your core arsenal. But how you deliver that is equally important - leadership and charisma play a massive part.

Knowledge can be learned. It would be nice if that were true of leadership and charisma.

For those lacking these traits, ‘Bottled Frustration’ and idealism can come to fore radiating fanaticism. At best in these cases the team will appear to be moving forward, but in reality the escalator that is the organization slowly moves them backwards.

This is the first in a series of entries exploring ActiveRecord associations through tests. I start with the simplest theoretical form – a one-to-one.

The MySQL schema driving the tests follows.

create table parents (
    id                   int not null auto_increment,
    created_on    datetime not null,
    updated_on   datetime not null,
    lock_version int default 0,
    name             varchar(15) not null,
    primary key (id)
) type=InnoDB;

create table children (
    id                   int not null auto_increment,
    parent_id       int not null,
    created_on    datetime not null,
    updated_on   datetime not null,
    lock_version int default 0,
    name             varchar(15) not null,
    constraint fk_children_parent foreign key (parent_id) references parents(id),
    primary key (id)
) type=InnoDB;

It’s a simple child -> parent relationship, the tables are named accordingly and conform to ActiveRecord’s pluralization demands. I’ve included the columns created_on, updated_on and lock_version mostly to exercise the features that automatically populate these values, but I occasionally put these columns to use in the tests.

The object representation of these tables, the Parent and Child classes, follow.

class Parent < ActiveRecord::Base
    has_one :child, :dependent => true
    has_one :youngest_child, :class_name => “Child”, :order => “created_on DESC”
end

class Child < ActiveRecord::Base
    belongs_to :parent
    belongs_to :mother, :class_name => “Parent”, :foreign_key => “parent_id”, :conditions => “name = ‘Mother’”
end

I’ve included simple uses of the class methods for forming the association (has_one and belongs_to) as well as the odder order clause filtering a parents one-to-many view of its children to a one-to-one and the conditions clause that filters a child’s view of a parent.

In total that’s a staggering 8 lines for a fair amount of features.

Let’s fire up some tests and see what’s happening under the hood.

As a sanity check let’s try and save a Parent.

    def test_create_successfully_persists_parent
        parent = Parent.create(:name => "parent1")
        assert(!parent.new_record?)
        assert_not_nil(parent.id)
        assert_not_nil(Parent.find(parent.id))
    end

Now how about a Child?

    def test_create_without_parent_causes_foreign_key_constraint
        assert_raise(ActiveRecord::StatementInvalid) { Child.create(:name => "child2") }
    end

OK, so the child needs a parent. For those of you with Agile Web Development with Rails this goes against the grain of what’s recommended on page 230, but that approach would work if the FK to Order was nullable (although that makes no conceptual sense).

So lets try building (unpersisted) a Child and assigning that directly to a created (persisted) Parent.

    def test_new_child_assigned_to_parents_child_persists_association
        parent = Parent.create(:name => "parent3")
        parent.child = Child.new(:name => "child3")
        assert(!parent.child.new_record?)
        assert_not_nil(parent.child.id)
        found_parent = Parent.find(parent.id)
        assert_equal(parent.child, found_parent.child)
    end

I find it unusual that assigning an unpersisted Child to a persisted Parent immediately persists the Child. It feels like ‘persistence by touch’ - but as we’ll see shortly persisted objects don’t always persist other objects they touch.

Lets reverse things around - what happens if a created Child persists a new/built Parent?

    def test_assigning_new_parent_to_created_child_does_not_persist_association
        old_parent = Parent.create(:name => "parent4")
        child = Child.create(:name => "child4", :parent => old_parent)
        # To create a child we need an existing parent.
        child.parent = Parent.new(:name => "new_parent4")
        assert(child.parent.new_record?)
        assert_nil(child.parent.id)
        assert_equal(old_parent, Child.find(child.id).parent)
    end

This is a rather unconventional way to attempt to establish the relationship, so ActiveRecord doesn’t support it. It is more logical that the parent exist before the child. In this way, ActiveRecord encourages you to work parent->child when navigating your objects.

Lets now look at the pseudo one-to-one mapping, the order clause.

    def test_parent_allows_multiple_children_and_youngest_is_as_expected
        parent = Parent.create(:name => "parent5")
        oldest_child = Child.create(:name => "many_child_1", :parent => parent)
        sleep(1)
        youngest_child = Child.create(:name => "many_child_2", :parent => parent)
        assert_equal(parent, oldest_child.parent)
        assert_equal(parent, youngest_child.parent)
        # That's not one-to-one!
        assert_equal(youngest_child, parent.youngest_child)
    end

So it’s not pure one-to-one, but virtual one-to-one relationships of this type can prove handy.

Now let’s try the conditions clause.

    def test_conditions_clause_returns_parent_if_parent_matches_condition
        parent = Parent.create(:name => "Mother")
        child = Child.create(:name => "child6", :parent => parent)
        assert_equal(parent, child.mother)
    end

That ends our tour of one-to-one associations.

Before I sign-off, while writing these tests I stumbled across some unusual results usually brought about by newbie syntactic errors. Here’s an example:

    def test_child_reload_is_forced_if_the_argument_is_not_a_boolean
        parent = Parent.create(:name => "parent7")
        parent.child = Child.new(:name => "child7")
        child = parent.child
        assert_equal(parent.child(child), parent.child(true))
        # Both of these methods reload the child.  Ouch.
    end

OK, so occasionally it would be nice to use a static language

True to the mantra of Rails, ActiveRecord makes persistence staggering simple. I still raise an eyebrow to persistence being this simple:

class User < ActiveRecord::Base
end

Yep, that’s all that’s needed to map to a table named users. ActiveRecord instantly generates a heap of methods and a few fields in the class facilitating CRUD operations with the table.

While I’ll defer from presenting the essentials of ActiveRecord (there’s plenty of material out there) here’s a teaser; fields will be automatically generated in the class representing each of the tables columns and methods like find_by_name_and_role (aka instant finders) will also be added, presenting queries in DSL form.

While simplicity is beauty, Java developers cringe at the prospect of using an Active Record approach to persistence, mixing the concerns of persistence with the domain model. Their accustomed to the Data Mapper approach employed by prominent Java ORM tools. Their mantra is all about a clean separation of layers to facilitate testability, maintainability, comprehension and to a lesser degree task separation. From their point of view, if you use that User object in a context where persistence is not needed you’ve got that extra persistence baggage hanging around.

Java developers sink deeper into their seats when they learn how prominent class methods (aka static methods) are in ActiveRecord. Out the window go pluggability and testability in comes a tight domain language (not so bad) and so called ‘unit tests’ that integrate with the database (not so good).

So me being one of those Java developers passionate about clean layer separations and anal enough to blast colleagues for incorrect use of the term ‘unit test’ – sure, I’ve shaken my head and cringed a tad. But for pure simplicity, hats off to the ActiveRecord team.

I guess it’s a contrast in two style of elegance; simplicity vs. conventional OO design. It’s interesting to note that latter is often considered an art taking years to grasp, while the former perhaps requires much less of a mental investment. But in saying that, part of the simplicity of ActiveRecord and Rails is that some of the OO design decisions are made for you. The layers are already clearly defined (although the persistence and domain layers are blurred), the tools already chosen.

But shifting the focus back to ActiveRecord, do I really care about that blurring if persistence of my domain model is a key concern of my application? Heck no. I can still test my domain logic without persisting a thing. I don’t have to configure a mapping layer, I just stick to ActiveRecord’s numerous naming conventions and it does that for me. The benefits outweigh the merit of conventional OO wisdom.

While I’ve been learning the finer details of ActiveRecord and appreciating its simplicity, I’ve been occasionally confused by a feature or design decision made by the ActiveRecord team. Top of the pops are the features added to classes involved in one-to-one, one-to-many and many-to-many associations.

So in my next few blogs I’ll demonstrate these features through tests, something that would have been a handy accompaniment to the explanations of these associations in Agile Web Development with Rails.

Note: For those after a detailed comparison of ActiveRecord and Hibernate, the Hibernate vs. Rails Showdown posted almost a year ago on TheServerSide quickly sketches out the differences.