Advanced Active Record in Rails 4
- 9.1 Scopes
- 9.2 Callbacks
- 9.3 Calculation Methods
- 9.4 Single-Table Inheritance (STI)
- 9.5 Abstract Base Model Classes
- 9.6 Polymorphic has_many Relationships
- 9.7 Enums
- 9.8 Foreign-Key Constraints
- 9.9 Modules for Reusing Common Behavior
- 9.10 Modifying Active Record Classes at Runtime
- 9.11 Using Value Objects
- 9.12 Nonpersisted Models
- 9.13 PostgreSQL Enhancements
- 9.14 Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
- Respectful debate, honesty, passion, and working systems created an environment that not even the most die-hard enterprise architect could ignore, no matter how buried in Java design patterns. Thosewho placed technical excellence and pragmaticism above religious attachment and vendor cronyism were easily convinced of the benefits that broadening their definition of acceptable technologies could bring.
- —Ryan Tomayko1
Active Record is a simple object-relational mapping (ORM) framework compared to other popular ORM frameworks, such as Hibernate in the Java world. Don’t let that fool you, though: Under its modest exterior, Active Record has some pretty advanced features. To really get the most effectiveness out of Rails development, you need to have more than a basic understanding of Active Record—things like knowing when to break out of the one-table/one-class pattern or how to leverage Ruby modules to keep your code clean and free of duplication.
In this chapter, we wrap up this book’s comprehensive coverage of Active Record by reviewing callbacks, single-table inheritance (STI), and polymorphic models. We also review a little bit of information about metaprogramming and Ruby domain-specific languages (DSLs) as they relate to Active Record.
9.1 Scopes
Scopes (or “named scopes” if you’re old school) allow you to define and chain query criteria in a declarative and reusable manner.
1 class Timesheet < ActiveRecord::Base
2 scope :submitted, -> { where(submitted: true) }
3 scope :underutilized, -> { where('total_hours < 40') }To declare a scope, use the scope class method, passing it a name as a symbol and a callable object that includes a query criteria within. You can simply use Arel criteria methods such as where, order, and limit to construct the definition as shown in the example. The queries defined in a scope are only evaluated whenever the scope is invoked.
1 class User < ActiveRecord::Base
2 scope :delinquent, -> { where('timesheets_updated_at < ?', 1.week.ago) }Invoke scopes as you would class methods.
>> User.delinquent
=> [#<User id: 2, timesheets_updated_at: "2013-04-20 20:02:13"...>]
Note that instead of using the scope macro-style method, you can simply define a class method on an Active Record model that returns a scoped method, such as where. To illustrate, the following class method is equivalent to the delinquent scope defined in the previous example.
1 def self.delinquent
2 where('timesheets_updated_at < ?', 1.week.ago)
3 end
9.1.1 Scope Parameters
You can pass arguments to scope invocations by adding parameters to the proc you use to define the scope query.
1 class BillableWeek < ActiveRecord::Base
2 scope :newer_than, ->(date) { where('start_date > ?', date) }
Then pass the argument to the scope as you would normally.
BillableWeek.newer_than(Date.today)
9.1.2 Chaining Scopes
One of the benefits of scopes is that you can chain them together to create complex queries from simple ones:
>> Timesheet.underutilized.submitted.to_a
=> [#<Timesheet id: 3, submitted: true, total_hours: 37 ...
Scopes can be chained together for reuse within scope definitions themselves. For instance, let’s say that we always want to constrain the result set of the underutilized scope to only submitted timesheets:
1 class Timesheet < ActiveRecord::Base
2 scope :submitted, -> { where(submitted: true) }
3 scope :underutilized, -> { submitted.where('total_hours < 40') }
9.1.3 Scopes and has_many
In addition to being available at the class context, scopes are available automatically on has_many association attributes.
>> u = User.find(2)
=> #<User id: 2, username: "obie"...>
>> u.timesheets.size
=> 3
>> u.timesheets.underutilized.size
=> 1
9.1.4 Scopes and Joins
You can use Arel’s join method to create cross model scopes. For instance, if we gave our recurring example Timesheet a submitted_at date attribute instead of just a boolean, we could add a scope to User allowing us to see who is late on their timesheet submission.
1 scope :tardy, -> {
2 joins(:timesheets).
3 where("timesheets.submitted_at <= ?", 7.days.ago).
4 group("users.id")
5 }
Arel’s to_sql method is useful for debugging scope definitions and usage.
>> User.tardy.to_sql
=> "SELECT "users".* FROM "users"
INNER JOIN "timesheets" ON "timesheets"."user_id" = "users"."id"
WHERE (timesheets.submitted_at <= '2013-04-13 18:16:15.203293')
GROUP BY users.id" # query formatted nicely for the book
Note that as demonstrated in the example, it’s a good idea to use unambiguous column references (including the table name) in cross model scope definitions so that Arel doesn’t get confused.
9.1.5 Scope Combinations
Our example of a cross model scope violates good object-oriented design principles: It contains the logic for determining whether or not a Timesheet is submitted, which is code that properly belongs in the Timesheet class. Luckily, we can use Arel’s merge method to fix it. First, we put the late logic where it belongs—in Timesheet:
scope :late, -> { where("timesheet.submitted_at <= ?", 7.days.ago) }
Then we use our new late scope in tardy:
scope :tardy, -> {
joins(:timesheets).group("users.id").merge(Timesheet.late)
}
If you have trouble with this technique, make absolutely sure that your scopes’ clauses refer to fully qualified column names. (In other words, don’t forget to prefix column names with tables.) The console and to_sql method is your friend for debugging.
9.1.6 Default Scopes
There may arise use cases where you want certain conditions applied to the finders for your model. Consider that our timesheet application has a default view of open timesheets—we can use a default scope to simplify our general queries.
class Timesheet < ActiveRecord::Base
default_scope { where(status: "open") }
end
Now when we query for our Timesheets, by default, the open condition will be applied:
>> Timesheet.pluck(:status)
=> ["open", "open", "open"]
Default scopes also get applied to your models when building or creating them, which can be a great convenience or a nuisance if you are not careful. In our previous example, all new Timesheets will be created with a status of “open.”
>> Timesheet.new
=> #<Timesheet id: nil, status: "open">
>> Timesheet.create
=> #<Timesheet id: 1, status: "open">
You can override this behavior by providing your own conditions or scope to override the default setting of the attributes.
>> Timesheet.where(status: "new").new
=> #<Timesheet id: nil, status: "new">
>> Timesheet.where(status: "new").create
=> #<Timesheet id: 1, status: "new">
There may be cases where at runtime you want to create a scope and pass it around as a first-class object leveraging your default scope. In this case, Active Record provides the all method.
>> timesheets = Timesheet.all.order("submitted_at DESC")
=> #<ActiveRecord::Relation [#<Timesheet id: 1, status: "open"]>
>> timesheets.where(name: "Durran Jordan").to_a
=> []
There’s another approach to scopes that provides a sleeker syntax: scoping, which allows the chaining of scopes via nesting within a block.
>> Timesheet.order("submitted_at DESC").scoping do
>> Timesheet.first
>> end
=> #<Timesheet id: 1, status: "open">
That’s pretty nice, but what if we don’t want our default scope to be included in our queries? In this case, Active Record takes care of us through the unscoped method.
>> Timesheet.unscoped.order("submitted_at DESC").to_a
=> [#<Timesheet id: 2, status: "submitted">]
Similarly to overriding our default scope with a relation when creating new objects, we can supply unscoped as well to remove the default attributes.
>> Timesheet.unscoped.new
=> #<Timesheet id: nil, status: nil>
9.1.7 Using Scopes for CRUD
You have a wide range of Active Record’s CRUD methods available on scopes, which gives you some powerful abilities. For instance, let’s give all our underutilized timesheets some extra hours.
>> u.timesheets.underutilized.pluck(:total_hours)
=> [37, 38]
>> u.timesheets.underutilized.update_all("total_hours = total_hours + 2")
=> 2
>> u.timesheets.underutilized.pluck(:total_hours)
=> [39]
Scopes—including a where clause using hashed conditions—will populate attributes of objects built off of them with those attributes as default values. Admittedly, it’s a bit difficult to think of a plausible case for this feature, but we’ll show it in an example. First, we add the following scope to Timesheet:
scope :perfect, -> { submitted.where(total_hours: 40) }
Now building an object on the perfect scope should give us a submitted timesheet with 40 hours.
> Timesheet.perfect.build
=> #<Timesheet id: nil, submitted: true, user_id: nil, total_hours: 40 ...>
As you’ve probably realized by now, the Arel underpinnings of Active Record are tremendously powerful and truly elevate the Rails platform.