賣文檔？是一條路子

https://github.com/schneems/puma_worker_killer 这个搞上？

redis-server 需要起两个吧

https://ruby-china.org/topics/11997#reply27

添加了多实例模式，可以用来做会签之类需求：https://github.com/hooopo/petri_flow/pull/16

.net 的？

应该可以用 proc 吧

awesome

支持子流程：https://github.com/hooopo/petri_flow/pull/15

之前一直以为工作流这东西是把简单的事情复杂化，大部分需求 Rails 的 state-machine 可以解决，实在不行 FSM 也可以解决，后来发现很多定制化的需求没有工作流引擎实现起来超级复杂。

工作流主要解决的是What，How，Who的问题，应用其实挺广泛，从钉钉这类审批系统和 SaaS 里的流程定制，到数据处理系统的调度，比如 Airflow，再到自动化流程控制，比如各种 CI/CD 工具，甚至项目管理工具，里面的核心都是工作流引擎。

Petri Flow 和 FlowCore 的主要区别是解不解决Who这个维度。

加了一个 Guard 表达式扩展，可以使用 JavaScript 来做逻辑复杂的 guard 条件。

理论上是不需要的，但实际上，后端还没有智能到可以把处理 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 或者云存储

酒仙桥?