Trim21
[POST] /indices//subjects 不用返回条目信息了吧
也有道理。
先不做（
感觉这个PR一次加的东西有点多，要不先做目录条目增改删，其他的分开PR
sai老板目前给了目录条目的增改删权限，如果先做这个的话可以合并之后直接上线。然后目录表的增改还没给，大概可以跟前一个一起PR。 目录删除的话还要涉及目录留言和用户条目收藏两个表的删除权限，放在用户条目收藏API之后再PR比较好。（用户留言好像不删除，直接留在那也行，反正也看不到了） 没对应数据库权限的PR合了之后还要考虑额外加flag来启用，开发和部署都挺难受的…
这个searchable的设置居然是带权重的…
> summery部分可否通过更改jieba的词库，来达到让其不要把一些很泛泛的词分出来的效果？可能能避免一些比较离谱的结果 应该可以吧？
需要先有一位热心开发者把issue里面提到的这些问题解决一下，summary过滤可以留在后面...
现在一共 40w 条条目，每天更新排名会更新几十万条数据。经过一段时间之后 meilisearch 就会崩溃并且无法写入，虽然删除旧文件并且重建搜索只需要半小时，但是需要额外盯着监控系统确定 meilisearch 没有挂掉... 🤔 不知道是 meili 本身的问题还是我们误用了，也可能是 meili 可能不太适合这种使用场景。 暂时的解决方案直接忽略掉binlog里面排名这一列的更新，只有在别的列更新的时候才会触发数据更新，更新整个条目数据。所以现在 meili 里的数据的排名大概率不准。 如果未来这个问题比较严重，可能考虑放弃现在的近实时更新改为每周更新，或者改用 ES。 上游有些相关的 issue，可能在 v0.30 能被修复 https://github.com/meilisearch/meilisearch/issues/2628
> 这些更新是一次性提交的，还是一个个提交的？后者会创建10w次更新任务（如果没有主动开启自动batch的话） 开了auto-batch分别提交的，看grafana,meili大概是分成了3个batch处理 不开batch的话meili的处理速度跟不上，会一直积累任务 ...