列表块“一炮三响”问题现状和改进提议

本贴最后更新于 1133 天前,其中的信息可能已经时异事殊

现状

众所周知,一个列表块至少包含了三个块。例如 * foo 的列表块实际的语法树结构和对应的 Markdown 为:

  1. 列表块容器 * foo
  2. 列表项块容器 * foo
  3. 段落块 foo

其对应的数据库表行数据为:

类型 markdown content
l * foo foo
i * foo foo
p foo foo

问题

这就导致在数据库上查询 foo 时,会同时命中三行,也就是“一炮三响”问题。当存在子列表时该问题尤为突出,表现为所有子列表上重复一次。例如:

* foo
  * bar

其对应的数据库表行数据为:

类型 markdown content
l * foo
* bar
foobar
i * foo
* bar
foobar
p foo foo
l * bar bar
i * bar bar
p bar bar

当搜索 bar 时,会命中 5 行作为结果集。

之前的改进

在搜索时加入了类型过滤,可以设置为过滤容器块,这样上述示例的搜索结果将减少为 1 行,即段落块 bar。

新改进提议

考虑在列表块和列表项块上的 markdown 和 content 字段上仅存储第一个块级子节点内容:

类型 markdown content
l * foo
foo
i * foo
foo
p foo foo
l * bar bar
i * bar bar
p bar bar

搜索 bar 时命中三行,即仅在当前列表块“一炮三响”。这个改进逻辑也匹配 引用容器块时自动渲染锚文本改进 #3126列表项折叠,除第一个子块外其余子块都隐藏 #3142

更进一步

容器块上的 markdown 和 content 字段完全留空,搜索时仅命中叶子块。

影响范围

  • 对通过子级搜索父级的逻辑会产生影响,比如想搜索同时包含分散在列表项上的某些关键字的父级列表就比较困难,但实现复杂度应该低于之前去重子级的复杂度
  • 已有的一些查询逻辑可能会冗余(为了排除父级),但应该不会产生副作用
  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统,支持完全离线使用,同时也支持端到端加密同步。

    融合块、大纲和双向链接,重构你的思维。

    22332 引用 • 89358 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • audiolabj 1 1 赞同

    几点浅见:

    1. 对于单一搜索关键词而言,将所有自身 Content 匹配的块(不论是容器块还是叶子块,只要这个块本身的内容(包含扩展属性)匹配搜索条件)作为搜索结果逐条显示,应该符合搜索者的直观期望,所以建议结果中保留这些容器块,可以通过图标和排序的方式(类似于文件命关键字搜索结果中的匹配文件夹和匹配文件的排列)来区隔
    2. 如果除了想获得匹配搜索的节点,还想看到节点归属的各上级容器节点,建议是否可以在结果里包含”块面包屑路径“且路径上每个节点都可以直接点击查看;这样可以解决”查看包含 < 关键字 > 的容器节点“的需求,目前思源给出了结果块归属的文档路径(全路径,但每个节点不可单独点击),是否可以再给出块的面包屑 —— 例如:查询包含 CNN 内容的节点,以及包含这些节点的各层容器块,查询结果中仅列出实际包含该内容的某个块,通过这个块的面包屑路径,自然带出各容器节点,上述容器节点不会直接列在查询结果中,既压缩了结果占用的空间,又可以通过这个结果节点的面包屑直观访问
    3. 对于 fangly 用户提出的复合关键字查询,且每个关键字匹配在不同层级节点的情形,这个在理解上可以类比网页搜索,查看同时包含"foo"和"bar"的内容,一个 content="foobar"的节点属于直观匹配,但是一个二级子节点包含"foo"且四级子节点包含"bar"的容器节点,是否应该符合”直观“的匹配结果呢?如果这个节点符合,那么包含这个节点的所有容器节点,乃至整个文档,以及该文档的父文档,是否也应该算符合呢?毕竟思源笔记的架构上,文档-子文档-容器块-叶子块,在使用逻辑上是无缝的;网页的搜索结果会把包含"foo"和"bar"的网页全部展示,只是按 page ranking 排序,匹配的字加亮显示。因此这样的需求,可能不同的搜索者,期望不同,用”宁可重复,也不漏掉“的原则处理似乎是恰当的。
  • 其他回帖
  • 88250

    @participants GitHub issues 上有个新的思路请各位帮忙 review 一下 Issue #5769 · siyuan-note/siyuan

  • HerbertHe

    在给 Vditor 开发自定义渲染器和 Lute PR renderJSON 这个方法的时候,我就发现了这个问题,这也是 renderJSON 这个方法为啥设置 Flag 这个特性的原因。对于起装饰性作用的块并不需要保留子节点内容,不然会造成导出语法树数据的冗余。

    还有个问题是开发自定义渲染器,使用 API 获取数据的情况其实并不一致,这个给自定义渲染器提出了很大的挑战。

  • 容器块增加一个深度字段不知道能不能解决问题 但是我也不知道这个好不好加 ......

    这样通过 sql 查询的时候能够直接指定深度或者通过深度排序截断过滤不需要的结果

  • 查看全部回帖