Step 2 – All articles with at least one similar tag

Step 3 – Unwind by tags

If you’re not familiar with unwind look here. That way, we get article copy for every tag for each article.

{ "$unwind" => "$tags" }

Step 4 – Second matching

You may wonder, why we filter results again. Well The initial filtering was not required, but we did this to remove all non-related articles, so the data set is much smaller. Unfortunately unwind created document copy per each of the tags – even those that we don’t want to. That’s why we have to filter it again.

"$match" => {
tags: { "$in" => %w{ ruby rails mongoid mongodb } }
}

Note that we don’t need to filter out again by ID, since in incoming dataset we already don’t have the current_article document instance.

Step 5 – Grouping

Now we can group by documents ID. Also we will add sum for grouping, so we will know similarity level for each document. One point in sum equals one similar matching tag.

{ "$group" => {
_id: "$_id",
matches: {"$sum" =>1}
}
}

Step 6 – Sorting

Now we can sort by sum to have elements in descending order (most similar on top):

{ "$sort" => {matches:-1} }

Step 7 – 10 first elements

And the last step – limiting:

{ "$limit" => 10 }

Making it all work together

In order to execute this whole code in Ruby, we need to use Article.collection.aggregate method:

We won’t get Ruby objects as a result (we’ll get an array of hashes). We can process it further if we need similarity level, but if we just need similar articles (for example to display them) we can just:

It is really good habit to review source code of each new Rails release (or at least a changelog file). Today while reviewing this release note, I’ve noticed, that the Rails team is going to revert the ActiveRecord#order functionality, so it will work like in the 3.2 version.

I must say, that I’m a bit disappointed. I really got used to this functionality and I used it really often. It was quite convenient to create scopes with default sorting, that could be easily “overwritten” by any other. Of course after that change I can still use the reorder method, to get exactly same effect, but it will require a lot of changes in the code. Also IMHO it seems kinda unfair – I put a lot of effort to migrate from Rails 3.2 to Rails 4.0.0 (stable) and it seems, that some of that work just got wasted, because Rails guys seem to be a bit unstable. I can understand behaviour changes between major releases, but this is just a fuck*ng small one!

If you’re not willing to spend a lot of time getting back to previous ordering mode (and dealing with it), you can use this monkey patch (put it into config/initializers) to keep the current (4.0.0) ordering behaviour:

Rafaels says that 4.0.1 ordering will stay as a default one, although I would not recommend doing any hasty moves now. I think it’s worth waiting at least few months to find out, if they are not going to change it again soon.

Meanwhile you can review Github commit with this change. Also be prepared for the shitstorm that is coming on Thursday (4.0.1 release day)…