Bachue's Blog

我发现写Rails，尤其是测试部分，需要reload的次数相当频繁。比方说

user = users(:xxxxx)
xhr :put, 'change_xxxxx', :id => user.id
user.reload # necessary!
assert user.xxx, xxx
assert user.yyy, yyy

由于这里创建的user对象和被测试的action里的user对象（在内存概念上）不是同一个对象，因此，被测试的action修改了user对象在数据库里的数据，会导致外围的user信息过时，因此必须reload，否则接下来的断言语句都无法通过。

这种情况同样也有可能存在与关联对象上，比如

assert child1.father, child2.father
child1.father.name = 'new name'
child1.save
child2.reload # necessary!
assert child2.father.name, 'new name'

总是写很多reload语句显然很不舒服，为此我今天在回家的地铁上想了一种解决方案，就是在后台全局的部分，以ActiveRecord类名和实例为key简单的缓存一部分数据，这部分数据与数据库里的数据在本次request返回内一致，request结束后自动清除以免内存泄露和影响下一个request。而前面的ActiveRecord对象，本身仅存储那些还未被保存的数据。

方案大致是这样的（以Rails 2.3为例）：

require 'active_record'

module ActiveRecord
  class Base
    def request_cache
      self.class.request_cache[self]
    end

    def request_cache=(v)
      self.class.request_cache[self] = v
    end
  end

  class << Base
    def request_cache
      @request_cache ||= Hash.new {|h, k| h[k] = Hash.new {|h, k| h[k] = {}}}
      @request_cache[name]
    end
  end
end

ActionController::Dispatcher.middleware.use(Class.new do
  def initializer(app)
    @app = app
  end

  def call(env)
    @app.call(env)
  ensure
    ActiveRecord::Base.request_cache.clear
  end
end)

这里我把缓存就设计在ActiveRecord的class variable内（三级Hash，分别是类-实例对象-属性名），然后用Middleware的方式去清理缓存，之所以选择用Middleware的方式是因为ActiveRecord原本和HTTP Request是不能发生关联的，否则Console和Unit test里就无法执行了，设计成Middleware则能很好的解决这一问题。

由于选择的三级Hash的设计中没有直接和数据库关联的信息，因此其实也可以用于非ActiveRecord类（唯一要做的可能仅仅是自己实现一种标示方法），毕竟当前可以用于存储的服务早已不止数据库一种了。

至于对于ActiveRecord的修改我现在对ActiveRecord的实现还不够熟悉，无法完成，以后学习这一部分了再说吧。但是大致的思路是这样的：

• 当从数据库读入数据的时候(包括reload)，将缓存里的数据翻新
• 当保存数据进数据库的时候，将数据同样保存进缓存
• 当从一个ActiveRecord对象读取属性的时候，现在被当前对象修改过的属性中搜索，如果搜索不到再从缓存里搜索，如果还是搜索不到就采用默认方法

大致就是这些了，其实想法还是很简单的，希望早日自己能把它变成现实。

为什么这么说呢？从没有见过运用如此广泛，几乎是所有Ruby Web Framework基础的开源项目中，这个文件里竟然有如此之多令人费解的部分（完全可以认为是Bug）

简单的举个例子吧，首先，对于Rack来说，.ru文件和.rb文件的区别在哪里？

def self.parse_file(config, opts = Server::Options.new)
  options = {}
  if config =~ /\.ru$/
    cfgfile = ::File.read(config)
    if cfgfile[/^#\\(.*)/] && opts
      options = opts.parse! $1.split(/\s+/)
    end
    cfgfile.sub!(/^__END__\n.*\Z/m, '')
    app = new_from_string cfgfile, config
  else
    require config
    app = Object.const_get(::File.basename(config, '.rb').capitalize)
  end
  return app, options
end

代码中告诉了我们答案，如果是.ru文件，Rack::Builder不仅仅会将其读出，而且还会从中解析出以#\开头的部分，作为Rack::Server启动的选项，举个例子：

#\--port 3000
run Proc.new {|env| [200, {"Content-Type" => "text/html"}, "Hello Rack!"]}

比如这个config.ru文件，rackup在执行这个文件是将启动出3000端口的服务器而非9292。

这本来是个不错的设计啦，但是仔细看代码就会发现，只支持一个选项，第二个选项用方括号运算符是匹配不到的，额。。。你妹。。

不得不承认Rack::Builder支持map包含map，也就是形成树结构，这点不错。更重要的是Rack仅仅执行那些不得不执行的map的代码块，如果路由没匹配到就不予执行这些都很好。但是当你发现Rack::Builder没接收到一个请求就会创建一个新的URLMap对象然后把路由计算成正则表达式，并且计算出的正则表达式不予缓存，每次都重新计算，就会感觉之前争取到的性能在这里又浪费了的惋惜啊。。好吧，这一定是考虑到开发模式下的需求。

接着就是最坑的一个Bug了

require 'rack'

infinity = Proc.new {|env| [200, {"Content-Type" => "text/html"}, 'root']}
builder = Rack::Builder.new do
  map '/' do
    run infinity
  end

  use Rack::CommonLogger

  map '/version' do
    map '/' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, "infinity 0.1"] }
    end

    map '/last' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, "infinity beta 0.0"] }
    end
  end
end
Rack::Handler::Thin.run builder, :Port => 9292

curl 0.0.0.0:9292/version/last

虽然看上去结果应该是infinity beta 0.0，但实际上结果是root，额。。

这个Bug的关键在于use Rack::CommonLogger这句语句的位置，可以看到，它写在两个map的中间。而use方法是这么实现的：

def use(middleware, *args, &block)
  if @map
    mapping, @map = @map, nil
    @use << proc { |app| generate_map app, mapping }
  end
  @use << proc { |app| middleware.new(app, *args, &block) }
end

为了让middleware处于middleware stack的外面，代码先判断当前有没有执行过map方法，如果执行过的话，先将它放进middleware stack，外面放middleware对象。这样执行的时候就能先执行到middleware了(大概作者是这么想的，但是这么做完全是错的，实际情况是先放进middleware stack的先被执行到)。如果你没有执行过map方法，那么虽然现在middleware stack上看上去只有middleware对象，但是等会执行的时候会把map包进来，这样就解决问题了。但是它显然没有想到，如果我把use写两个map中间的情况。此时，middleware stack对象会先把第一个map写进去，然后跟着middleware。然后在下一个map执行的时候，重新赋值map对象，并在最后被middleware stack的两个元素包住。这样请求一进来的时候就会发现，竟然是第一个map直接接受请求，连middleware都不是（之前讲过，实际情况是先写进middleware stack的先被执行到）。

算起来好像只有把use语句写在所有map之前的时候才是能真正正常工作的。大概确实很少人不这么做吧，否则这么明显的问题为何不被解决呢。

虽然我们可以看到，Rack::Builder实现了自己的路由和middleware调用方法，但是无论是Rails还是Sinatra，都无一基于Rack::Builder，不仅仅是因为Rack::Builder没有更多的功能，已有功能也不容易扩展，而且，里面坑太多了，还不如自己从头写呢。