12.3 动态流
接下来我们要实现演示应用最难的功能:微博动态流。基本上本节的内容算是全书最高深的。完整的动态流以 11.3.3 节的动态流原型为基础实现,动态流中除了当前用户自己的微博之外,还包含他关注的用户发布的微博。我们会采用循序渐进的方式实现动态了。在实现的过程中,会用到一些相当高级的 Rails、Ruby 和 SQL 技术。
因为我们要做的事情很多,在此之前最好先清楚我们要实现的是什么样的功能。图 12.5 显示了最终要实现的动态流,图 12.21 是同一幅图。
12.3.1 目的和策略
我们对动态流的构思很简单。图 12.22 中显示了一个示例的 microposts
表和要显示的动态。动态流就是要把当前用户关注的用户发布的微博(也包括当前用户自己的微博)从 microposts
表中取出来,如图中的箭头所示。
图 12.21:某个用户登录后看到的首页,显示有动态流图 12.22:ID 为 1 的用户关注了 ID 为 2,7,8,10 的用户后得到的动态流
虽然我们还不知道怎么实现动态流,但测试的方法很明确,所以我们先写测试。测试的关键是要覆盖三种情况:动态流中既要包含关注的用户发布的微博,还要有用户自己的微博,但是不能包含未关注用户的微博。根据代码清单 9.43 和代码清单 11.51 中的固件,也就是说,Michael 要能看到 Lana 和自己的微博,但不能看到 Archer 的微博。把这个需求转换成测试,如代码清单 12.41 所示。(用到了代码清单 11.44 中定义的 feed
方法。)
代码清单 12.41:测试动态流 RED
test/models/user_test.rb
require 'test_helper'
class UserTest < ActiveSupport::TestCase
.
.
.
test "feed should have the right posts" do
michael = users(:michael)
archer = users(:archer)
lana = users(:lana)
# 关注的用户发布的微博
lana.microposts.each do |post_following|
assert michael.feed.include?(post_following)
end
# 自己的微博
michael.microposts.each do |post_self|
assert michael.feed.include?(post_self)
end
# 未关注用户的微博
archer.microposts.each do |post_unfollowed|
assert_not michael.feed.include?(post_unfollowed)
end
end
end
当然,现在的动态流只是个原型,测试无法通过:
代码清单 12.42:RED
$ bundle exec rake test
12.3.2 初步实现动态流
有了检查动态流的测试后(代码清单 12.41),我们可以开始实现动态流了。因为要实现的功能有点复杂,因此我们会一点一点实现。首先,我们要知道该使用怎样的查询语句。我们要从 microposts
表中取出关注的用户发布的微博(也要取出用户自己的微博)。为此,我们可以使用类似下面的查询语句:
SELECT * FROM microposts
WHERE user_id IN (<list of ids>) OR user_id = <user id>
编写这个查询语句时,我们假设 SQL 支持使用 IN
关键字检测集合中是否包含指定的元素。(还好,SQL 支持。)
11.3.3 节实现动态流原型时,我们使用 Active Record 中的 where
方法完成上面这种查询(代码清单 11.44)。那时所需的查询很简单,只是通过当前用户的 ID 取出他发布的微博:
Micropost.where("user_id = ?", id)
而现在,我们遇到的情况复杂得多,要使用类似下面的代码实现:
Micropost.where("user_id IN (?) OR user_id = ?", following_ids, id)
从上面的查询条件可以看出,我们需要生成一个数组,其元素是关注的用户的 ID。生成这个数组的方法之一是,使用 Ruby 中的 map
方法,这个方法可以在任意“可枚举”(enumerable)的对象上调用,[9]例如由一组元素组成的集合(数组或哈希)。我们在 4.3.2 节举例介绍过这个方法,现在再举个例子,把整数数组中的元素都转换成字符串:
$ rails console
>> [1, 2, 3, 4].map { |i| i.to_s }
=> ["1", "2", "3", "4"]
像上面这种在每个元素上调用同一个方法的情况很常见,所以 Ruby 为此定义了一种简写形式(4.3.2 节简介过)——在 &
符号后面跟上被调用方法的符号形式:
>> [1, 2, 3, 4].map(&:to_s)
=> ["1", "2", "3", "4"]
然后再调用 join
方法(4.3.1 节),就可以把数组中的元素合并起来组成字符串,各元素之间用逗号加一个空格分开:
>> [1, 2, 3, 4].map(&:to_s).join(', ')
=> "1, 2, 3, 4"
参照上面介绍的方法,我们可以在 user.following
中的每个元素上调用 id
方法,得到一个由关注的用户 ID 组成的数组。例如,对数据库中的第一个用户而言,可以使用下面的方法得到这个数组:
>> User.first.following.map(&:id)
=> [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42,
43, 44, 45, 46, 47, 48, 49, 50, 51]
其实,因为这种用法太普遍了,所以 Active Record 默认已经提供了:
>> User.first.following_ids
=> [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42,
43, 44, 45, 46, 47, 48, 49, 50, 51]
上述代码中的 following_ids
方法是 Active Record 根据 has_many :following
关联(代码清单 12.8)合成的。因此,我们只需在关联名后面加上 _ids
就可以获取 user.following
集合中所有用户的 ID。用户 ID 组成的字符串如下:
>> User.first.following_ids.join(', ')
=> "4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42,
43, 44, 45, 46, 47, 48, 49, 50, 51"
不过,插入 SQL 语句时,无须手动生成字符串,?
插值操作会为你代劳(同时也避免了一些数据库之间的兼容问题)。所以,实际上只需要使用 following_ids
而已。
所以,之前猜测的写法确实可用:
Micropost.where("user_id IN (?) OR user_id = ?", following_ids, id)
feed
方法的定义如代码清单 12.43 所示。
代码清单 12.43:初步实现的动态流 GREEN
app/models/user.rb
class User < ActiveRecord::Base
.
.
.
# 如果密码重设超时失效了,返回 true
def password_reset_expired?
reset_sent_at < 2.hours.ago
end
# 返回用户的动态流
def feed
Micropost.where("user_id IN (?) OR user_id = ?", following_ids, id) end
# 关注另一个用户
def follow(other_user)
active_relationships.create(followed_id: other_user.id)
end
.
.
.
end
现在测试组件应该可以通过了:
代码清单 12.44:GREEN
$ bundle exec rake test
在某些应用中,这样的初步实现已经能满足大部分需求了,但这不是我们最终要使用的实现方式。在阅读下一节之前,你可以想一下为什么。(提示:如果用户关注了 5000 个人呢?)
12.3.3 子查询
如前一节末尾所说,对 12.3.2 节的实现方式来说,如果用户关注了 5000 个人,动态流中的微博数量会变多,性能就会下降。本节,我们会重新实现动态流,在关注的用户数量很多时,性能也很好。
12.3.2 节中所用代码的问题是 following_ids
这行代码,它会把所有关注的用户 ID 取出,加载到内存,还会创建一个元素数量和关注的用户数量相同的数组。既然代码清单 12.43 的目的只是为了检查集合中是否包含了指定的元素,那么就一定有一种更高效的方式。其实 SQL 真得提供了针对这种问题的优化措施:使用“子查询”(subselect),在数据库层查找关注的用户 ID。
针对动态流的重构,先从代码清单 12.45 中的小改动开始。
代码清单 12.45:在获取动态流的 where
方法中使用键值对 GREEN
app/models/user.rb
class User < ActiveRecord::Base
.
.
.
# 返回用户的动态流
def feed
Micropost.where("user_id IN (:following_ids) OR user_id = :user_id", following_ids: following_ids, user_id: user) end
.
.
.
end
为了给下一步重构做准备,我们把
where("user_id IN (?) OR user_id = ?", following_ids, id)
换成了等效的
where("user_id IN (:following_ids) OR user_id = :user_id",
following_ids: following_ids, user_id: id)
使用问号做插值虽然可以,但如果要在多处插入同一个值,后一种写法更方便。
上面这段话表明,我们要在 SQL 查询语句中两次用到 user_id
。具体而言,我们要把下面这行 Ruby 代码
following_ids
换成包含 SQL 语句的代码
following_ids = "SELECT followed_id FROM relationships
WHERE follower_id = :user_id"
上面这行代码使用了 SQL 子查询语句。那么针对 ID 为 1 的用户,整个查询语句是这样的:
SELECT * FROM microposts
WHERE user_id IN (SELECT followed_id FROM relationships
WHERE follower_id = 1)
OR user_id = 1
使用子查询后,所有的集合包含关系都交由数据库处理,这样效率更高。
有了这些基础,我们就可以着手实现更高效的动态流了,如代码清单 12.46 所示。注意,因为现在使用的是纯 SQL 语句,所以使用插值方式把 following_ids
加入语句中,而没使用转义的方式。
代码清单 12.46:动态流的最终实现 GREEN
app/models/user.rb
class User < ActiveRecord::Base
.
.
.
# 返回用户的动态流
def feed
following_ids = "SELECT followed_id FROM relationships
WHERE follower_id = :user_id"
Micropost.where("user_id IN (#{following_ids}) OR user_id = :user_id", user_id: id)
end
.
.
.
end
这段代码结合了 Rails、Ruby 和 SQL 的优势,达到了目的,而且做的很好:
代码清单 12.47:GREEN
$ bundle exec rake test
当然,子查询也不是万能的。对于更大型的网站而言,可能要使用“后台作业”(background job)异步生成动态流。性能优化这个话题已经超出了本书范畴。
现在,动态流完全实现了。11.3.3 节已经在首页加入了动态流,下面再次列出来(代码清单 12.48),以便参考。第 11 章实现的只是动态流原型(图 11.14),添加代码清单 12.46 中的代码后,首页显示的动态流完整了,如图 12.23 所示。
代码清单 12.48:home
动作中分页显示的动态流
app/controllers/static_pages_controller.rb
class StaticPagesController < ApplicationController
def home
if logged_in?
@micropost = current_user.microposts.build
@feed_items = current_user.feed.paginate(page: params[:page]) end
end
.
.
.
end
现在可以把改动合并到 master
分支了:
$ bundle exec rake test
$ git add -A
$ git commit -m "Add user following"
$ git checkout master
$ git merge following-users
然后再推送到远程仓库,并部署到生产环境:
$ git push
$ git push heroku
$ heroku pg:reset DATABASE
$ heroku run rake db:migrate
$ heroku run rake db:seed
在生产环境的线上网站中也会显示动态流,如图 12.24 所示。
图 12.23:首页,显示有动态流图 12.24:线上网站中显示的动态流