a timocracy of one

Update: This doesn’t actually quite work, as it can override some scopes when composed. I haven’t quite figured out yet, if the technique is salvageable in some situations, or if it is always unsafe to use for chaining scopes.

I have not been able to find any info on ways to make rails named_scopes call each other, or otherwise handle dependencies. This can come up, for instance, if you have complex scopes that require joins. You might have some scopes that share the same needed set of joins to be valid, and you would like to spin that join out to a separate scope, so they could share it. Or it might be called from a has_many :through, where that join will already be valid, but alternatively called directly, where the qualified column name suddenly won’t make sense (‘other_table.column_name’ will be incorrrect in the unjoined query).

The best solution I have found is to use a class method that returns an anonymous scope. This is a contrived example that could be better handled through the has_many side of the relationship, but with sufficiently complex multi-level has_many :throughs you can easily come up with a situation where you want dependent named_scopes.

class Book
  named_scope :author_join, :joins => 'INNER JOIN authors ON books.author_id = authors.id, order => 'authors.last_name, authors.first_name'
  named_scope :published, :conditions => {:published => true}

  def by_author_country(country_code)
    Book.author_join.scoped(:conditions => ['authors.country_code = ?', country_code])
  end
end

#yes they are still composable
Book.by_author_country('EU').published

Just beware that currently scopes don’t merge joins, so you can only have one joins per set of composed scopes.

If you are hitting mysterious warnings of the format: “RangeError: 0×19ad692 is recycled object” in your tests, after upgrading to Rails 2.1, it might be due to threading issues. Just commenting out the line

require 'thread'

in a library at work, that will run without it, quieted the tests, so it’s possible even just requiring it will cause problems in Rails 2.1 (using ruby 1.8.6 p114).

Which is odd, since thread is required at least one place in the AR code itself, and elsewhere in our app. Maybe it’s an interplay of a couple libraries together, such as the non-threadsafe ‘aws/s3’ and thread?

def hello(message)
  "#{messsage}!" 
end
"1234foo4567foo".gsub /(\d*)foo/, hello($1)
=> "!!" 
"1234foo4567foo".gsub /(\d*)foo/, hello($1)
=> "4567!4567!" 

I needed to pass a backreference ($1 or \1) from a regexp into a parsing method and then replace the match with the result. I tried many ways and couldn’t quite figure out why I couldn’t do it, before realizing that the $n variables get populated based on the last match, so won’t be populated when passed into the method call in the substitution param, or will be populated from the last time it was run. And the ’\1’ for won’t work for similar, if slightly different reasons.

Then I discovered the block form of gsub, which passes in each match to the block, and populates all the relevant regexp backreference/match globals:

"1234foo4567foo".gsub(/(\d*)foo/){|m| hello($1)}
=> "1234!4567!" 

If you are using a has_finder (or possibly named_scope, I haven’t confirmed this myself), remember that unless you wrap your condition => in a lambda it is going to be evaluated early – or at least earlier than fixture creation, it seems. At work we had a case where one model had a finder that depended on its belong_to being in a subset of another, basically:

has_finder :all_active, {  :conditions => {:status_id => Status.active_ids} }

This work in production, where the ids don’t change, but since we are using the newer fixture approach on this model the ids are created dynamically. Given how fixtures load, the table will probably be populated with the old values, at parse time for that class, then the test will run, and the fixtures will reload, and they will not match anymore.

This is easily fixed, when you realize what is happening:

has_finder :all_active, lambda {|| {  :conditions => {:status_id => OtherModel.active_ids} }}

A friend and former employee of mine, Stephanie Geerlings is looking for work. She just put her new portfolio site up, so it’s missing a couple things, like a contact link, so go ahead and email her at stillsmall at gmail if you are interested. If it doesn’t go without saying, she comes recommended by me. ;)

This year was great for infographics of the primary season, over at the NYTimes. Good data visualizations definitely give you a better grasp on the data, and you can see all at once things that might have been hidden before. It seems to me creation of good infographics is a here to stay needed skill for online journalism and reporting now.

For instance, check this out to see that yes, despite the horse-race the media might make of it, Obama is going to win the general.