理论上是不需要的，但实际上，后端还没有智能到可以把处理 collection 和单条记录一样高效，比如 collection 的查询，都需要分页信息之类，虽然在 gql 这层是可以不查的，但后端同样需要 count 一次。

权限不是一个问题，gql 之后，权限其实不是基于 action 的，是基于 RLS 或 ACL 的。

用了 RUM 之后，基本上和 ES 差不多了，不过打分还是赶不上 ES

会……哈哈 机翻的

来集成一下你的 form core：https://github.com/hooopo/petri_flow/pull/9

https://github.com/ankane/searchkick/pull/924 现在应该支持了

searchkick

?????:??

解决的问题类似

其实 truncate 也可以 hook 掉

并不是

es 其实最大的优势是编程模型，对于历史状态的回溯不如上面的方法，因为存的是状态，而不是事件，事件需要再计算才能得到状态，挺麻烦的，而且会受代码逻辑影响。

@Rei 基于 model 的方案主要问题是 callback 容易绕过

@coderliu 这个会触发 model 的 after destroy 吗 @novtopro 类似了，不过我觉得方案三得对原理非常熟悉才能玩的转 上面没提到，那个 view 还得刷新，因为 view 生成的时候会把 select *变成静态的，里面引用的表结构变了的话，是不能动态更新到 view 的，需要 create or replace view 一下

老板说的对

有个东西叫 nfs 或者云存储

酒仙桥？

好吧，Schema、Migration 其实不是必须的，establish_connection 一下就好，不过即使写报表的话，也需要知道各个表的关联关系，有一份映射其实省去很多重复劳动。

为什么不建一个 model 呢，也不复杂；多表用 AR 只会更简单，查询场景越复杂用 AR 越简单。如果有场景的话，我可以用 AR 来演示一下。

update/delete其实不复杂 没必要 DSL 了

处理过类似的查询，从使用 AR 到 raw SQL，最后又回到了 AR

1. 其实各个数据库都有 adapter，AR 完全可以支持，比如 redshift：https://github.com/ConsultingMD/activerecord5-redshift-adapter TiDB 这种，只用 mysql adapter 就行
2. AR 也可以只做生成 SQL，query.to_sql 就行，甚至可以自己组合，比如 query1 = xxx; query2 = User.joins("INNER JOIN (#{query1.to_sql}) as t")
3. 二楼说的复用，AR 也可以：

query = User.where("id > 1").order("xx").limit("xx")
count = query.unscope(:select).unscope(:order).select("count(*)").group("id")

awesome env

消息队列

还是 flat map 清晰一些

不错

再发小广告删号了

Redis::CommandError: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error

👍

这个是公司的项目吗

看起来不错

只做缓存的话 memcache 呀 支持多线程

分享一下怎么解决的咯