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

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

现状

众所周知,一个列表块至少包含了三个块。例如 * 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 字段完全留空,搜索时仅命中叶子块。

影响范围

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

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

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

    20156 引用 • 77717 回帖

相关帖子

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • fangly 1

    image.png

    在数据库改进了之后,想要在上面这个图中搜索同时包含 CNN 模型 和 RNN 模型 的块,要写非常非常复杂的 sql 讨论各种情况。

    知道块长什么样的话,那用非常复杂的 sql 肯定能搜出来,但现实使用过程中,我根本无法知道我笔记中“同时包含 CNN 模型 和 RNN 模型”的块是长什么样的,我只知道肯定有容器块包含了它们,而改进后的数据库无法对容器块进行搜索。

    原先的数据库设计下,对于这个场景,虽然可能会有重复,但至少保证我能搜索到所有可能有用的块,最后无非是在 sql 查询结果中看到重复的内容跳过不看,但我用 sql 本来就是在挑选后续可能有用的块,有重复内容其实无所谓,看到重复内容,花 1 秒钟识别出是重复的,跳过就好。

    个人觉得,“搜不到”比“有重复”带来的问题更加严重,一个是功能上的缺失,一个是体验上稍微麻烦点。

    2 操作
    fangly 在 2021-10-15 00:40:46 更新了该回帖
    fangly 在 2021-10-15 00:31:13 更新了该回帖
  • 其他回帖
  • 先占楼再看trollface


    疑虑 1:

    * foo
      * bar
    

    如果第一层的 i 只包含 * foo 不包含 * bar 了,会影响对 * foo 及其子列表的拖动和查询吗?这个太重要了。如果不能根据父节点查出子节点了,问题很大。

    疑虑 2:

    我分析问题的习惯是这样,一件事要先评估做与不做,而不是一开始就一头扎进对具体做法的思考。

    现在一炮三响对于熟练用户来说其实是很好解决的,就算要改进,我感觉主帖里写的这种改进方案带来的提升真的非常之小,还可能带来新的问题,而且也并没有提升对新手的友好程度(因为 l + i + p 的基本模型还是没变,如果一个新手从只会用 ctrl+p 进化到开始用 SQL 了,他在这轮改进之后面对的将是一个比原来更加不符合直觉的数据表)。

    不知道这轮改进的动机是什么,如果仅仅是为了解决搜索过程中的一炮三响,似乎没有什么改进的必要。

  • HerbertHe

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

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

  • leolee 1 2 赞同

    笔记内容比较多的时候更容易发生的问题是有些内容永远不会被看到 而不是一些内容过多的重复出现 我觉得可能相对偏宽松的命中范围可能比过于范围过于狭小的反馈更有利于笔记的常青

    因为检索需要本身就是因为我们不可能准确记住内容的所在位置而产生,从一个更加宽泛的检索结果去做减法往往比从狭窄的检索结果做加法容易,因为在前面一种情况下我们能看到自己要减去的是一些什么内容,而在后面一种情况下可能连想清楚可能有哪些内容没有覆盖都很难.

  • 查看全部回帖