This is now done via:
We no longer carry post ids in memory and the rebake task can be resumed by running posts:rebake_uncooked_posts.
One caveat here is that the resume task will not rebake posts in reverse order (i.e. the sort order will be id ascending).
If you need to rebake all posts instantly then run bundle exec rake posts:rebake.
Post.update_all("baked_version = NULL") will rebake 100 posts (by default) every 15 minutes.
Thanks, Arpit.
FYI, I encountered some performance issues with that approach, so I went with this, which alleviated the problem and resulted in the same outcome:
Post.in_batches.update_all('baked_version = NULL')
@techAPJ I have a dummy question. Where do you run this command? After entering the app?
It tells me
bash: syntax error near unexpected token ''baked_version = NULL''
./launcher enter app
rails c
Post.in_batches.update_all('baked_version = NULL')
批量方法是否适合处理大量重新烘焙任务？
2851000 / 27182220 ( 10.5%)
这是我们昨天使用常规重新烘焙命令启动后的当前进度，看起来大约每 3 秒处理 1000 条。我们已非常接近导入流程和测试的尾声，只是想确认在处理大型站点时是否有更合适的方法，而不是采用这种较慢的方式。
有人能解释一下这个 in_batches 版本是如何工作的吗？它大概是以批次进行重新烘焙，但根据上面的帖子，它默认每 15 分钟以 100 个为一批进行重新烘焙。
我有一个 200 万的重新烘焙工作要做，并试图找出最好的方法来完成它。这项工作并不紧急，但我想确保正常运行和管理操作（如备份）不受长时间运行的工作的影响。
那就迁移到更快的服务器。
要庆幸它没有压垮你的网站。整个过程的目的是防止这个过程消耗过多的资源，在过程中保持你的网站响应。
查阅源代码总是一个好主意：
确实，标记应该很快。rebake_post 似乎确实调用了 cooking。也许这其中或由此产生了一些异步任务？
是的，当然，这是一个生成一组作业的作业
这不是理想的解决方案，但我找到了另一种方法！
我写了一个自己的 re-baker，速度快了 1000 倍，所以它不再需要一个月，只需要几分钟。
我实际上会在数据库插入之前进行 re-bake，这样 re-bake 的成本就会在数据库插入时间内消失。
啊，好的，我不知道你的背景。
是的，这是为生产案例编写的。
出于好奇，你能分享一下你做了什么吗？
我编写了一个程序来扫描所有导入的帖子，以查找它们包含的标记/表情符号。然后，我编写了另一个程序将原始帖子烘焙成 HTML 并直接更新数据库。