#15 楼 @hooopo 其实不管从理念还是实现 ES 都是非常优秀的。我在开发类似应用的时候就参考了它的理念。只是简化了他的分布式处理，其他比如 json out|json in . RestFull 的 http 通信等都保留了。就目前对其 github (https://github.com/elasticsearch/elasticsearch) active 的观察，开发还是相当活跃的。而且开发者 kimchy 还是 compass 项目的开发者，在搜索领域算是非常有经验的一个人。

#26 楼 @Saito 我不知道为什么 Play 不实现这套机制 (http://www.iteye.com/topic/1125807.因为框架本身已经使用了字节码修改的技术。为何不做的彻底一点呢？) ps: 链接地址是一个 java 开源框架提供的是实现。非常测彻底。整个实现，包括 controller 层不超过一个月。其实大部门互联网应用核心就是 model 层。如果能简化 model 层，那么你的整个开发代码就简化了。

#23 楼 @Saito 而且 默认 AR 的 query interface 还是最简洁的。EBean 的查询方式看你的代码就比较无语了...典型的一个折中产物...

#23 楼 @Saito 说实话我不喜欢这种风格。 甚至

Order.where({:status=>1,:name=>"tt"});

这个 hash 做参数的方式我也不喜欢。 hash 做参数唯一的好处是方便直接接受用户传递来的参数构建 where 条件。否则我觉得最合服只觉得应该是

Order.where(“status=>1 and name=>'tt‘”);

#10 楼 @Saito play 的 Model 层并没有完全 ActiveRecord 化吧。依然使用 类似 Blog.find("where name=?","google") 这样的语法。

#1 楼 @jn615 不能够吧....

其实就是应该提出一个 data migration 最佳实践，并形成规范。一则减少风险，二则提高数据迁移效率

#9 楼 @hooopo elasticsearch 也可以不去建分片和 mapping 的。他又默认值。之所以提供那个选项，还是为了能让用户精准的控制自己的索引数据和结构类型。

title 里面的词汇使用 or 关系，body 使用 and 关系，title 和 body 之间使用 or 关系。然后 title 权重设置高一点。就能保证三条都搜索到，而且结果还挺好....