SQL 嵌入查询的致命缺陷：递归死循环与无法实现“原子级”内容聚合

问题图片

1. 应用场景与核心需求 (Use Case)

场景描述：

我正在构建一个基于思源笔记的深度知识管理系统（System）。我的核心工作流是：在长文档中对关键的“洞见”或“结论”进行高亮标记（通常使用 Alt+X 给整个块/列表项上色），然后希望通过 嵌入式 SQL 查询 (Embed SQL Query)，在文档顶部或汇总页自动聚合这些高亮内容，形成一个 Dashboard。

核心需求：

1. 聚合： 自动筛选出所有打了特定颜色属性（ial）的块。
2. 原子化展示： 我只希望看到被我标记的那一行内容。即便这个块是一个列表项（List Item），且下方包含大量子块（Sub-nodes），我也希望在查询结果中只渲染父级内容，而不带出下方所有子节点。
3. 同文档查询： 我经常需要在当前文档内部进行查询汇总（例如：在文档开头汇总本文档的所有高亮重点）。

2. 遇到的问题与情况还原 (Issue Reproduction)

在尝试通过 SQL 实现上述需求时，遇到了两个无法解决的底层逻辑冲突：

问题 A：镜像死循环 (Infinite Recursive Rendering)

当我在一篇文档内使用 SQL 查询“本文档内标绿的块”时，由于 嵌入查询块本身（或其父级容器）不可避免地会被卷入查询范围（例如查询块在标绿的列表下，或查询条件宽泛），导致渲染引擎陷入死循环。

• 现象： 查询结果中渲染了查询块本身，而那个渲染出来的查询块又再次执行查询……形成了“无限套娃”。

• 截图证据：

  [此处插入那张“查询结果里套着查询结果，无限重复”的截图]

问题 B：容器强制渲染子节点 (Forced Context Rendering)

当我对一个列表项（type='i'）使用 Alt+X 上色后，SQL 查询该块。

• 现象： 思源的渲染引擎强制将该列表项下方的所有子块（子列表、引用、图片等）全部渲染出来。哪怕我只想看第一行的结论，它也会把下方几千字的论证全部带出来。这导致聚合页面充满了无关的“噪音”。

• 截图证据：

  [此处插入那张“查询标题/列表项，结果下方未标绿的内容全被带出来”的截图]

3. 尝试过的方案 (Attempted Solutions)

为了解决上述问题，我尝试了极其复杂的 SQL 过滤逻辑，但均以失败告终：

1. 尝试阻断死循环：

   • 代码：AND content NOT LIKE '%SELECT%' 或 AND markdown NOT LIKE...
   • 结果：失败。 似乎在 SQL 过滤生效前，渲染管道就已经捕获了该块，或者在某些层级嵌套下无法排除自身。

2. 尝试阻断子节点渲染：

   • 代码：AND type != 'i' （排除列表项）
   • 结果：失败。 因为我用的是 Alt+X 给列表项上色，排除列表项后，我的数据就全丢了。
   • 尝试：使用子查询 SELECT * FROM blocks WHERE parent_id IN (标绿的列表项)
   • 结果：失败。 渲染逻辑依然混乱，且无法准确还原上下文。

3. 尝试只查原子类型：

   • 代码：AND type IN ('h', 'p')
   • 结果：失败。 只要标题或段落位于一个被渲染的容器内，容器依然会接管渲染行为。

4. 逻辑上预期的样子 (Expected Behavior)

我认为一个成熟的双链笔记数据库，在处理 Query 时应具备以下能力：

1. 自动防自爆机制： 嵌入式查询块 (Embed Query Block) 应该默认具备 "Self-Exclusion" (自我排除) 的逻辑。无论 SQL 怎么写，都不应该允许查询块渲染它自己，这是防止 UI 崩溃的底线。

2. “内容模式”渲染 (Content-Only Rendering)：

   • 目前的渲染逻辑是：Query Block -> Render Block(ID)。如果 ID 是列表项，则渲染整棵树。
   • 诉求： 需要一种机制（也许是 SQL 的某个参数，或者 UI 选项），允许用户 “只渲染块内容 (content)，忽略子节点” 。
   • 就像：SELECT content_only(id) ...。我只想要那个“箱子”上的标签，不想要“箱子”里的货。

5. 观点与诉求 (Conclusion)

目前的 SQL 查询功能在 “内容聚合” 这一高频场景下显得非常尴尬（Chicken Ribs）：

• 它能查到数据，但 渲染方式 极其不可控。
• 对于追求结构化笔记的用户（重度大纲/列表使用者），一旦使用了 Alt+X 排版，SQL 查询基本上就不可用了，因为无法剥离上下文。

强烈建议官方：

1. 修复同文档查询的死循环 Bug，在底层切断递归。
2. 引入“原子化渲染”选项，允许在嵌入查询中只展示块本身的文本，而不级联展示其子块。

这将极大地释放思源笔记作为“个人知识数据库”的潜力。希望能得到开发团队的重视。

附上几个错误代码：

这些代码都有这些问题，我尝试了 10 几个代码都无法解决这个问题：

SELECT * FROM blocks 
WHERE root_id = '20251210211043-chdub1j' 

-- 【防死循环绝对领域】
-- 排除代码块(c)和HTML块(m)。
-- 只要你的 SQL 写在代码块里，这一行能 100% 物理熔断死循环。
AND type NOT IN ('c', 'm')

AND (
    -- 【情况 A：你直接给文字/标题上了色】
    (
        type IN ('h', 'p') -- 只查标题和段落
        AND (
            ial LIKE '%background-color: var(--b3-card-info-background)%'
            OR ial LIKE '%background-color: var(--b3-card-success-background)%'
            OR ial LIKE '%background-color: var(--b3-card-warning-background)%'
            OR ial LIKE '%background-color: var(--b3-card-error-background)%'
        )
    )
  
    OR
  
    -- 【情况 B：你给圆点(列表项)上了色 (Alt+X 的习惯)】
    -- 这里的逻辑是：查那些“爸爸是绿色列表项”的段落。
    -- 这样查出来的是“段落(p)”，而不是“容器(i)”，所以绝对不会带出子节点！
    (
        type = 'p' -- 我只显示文字
        AND parent_id IN (
            SELECT id FROM blocks 
            WHERE root_id = '20251211235937-ewjmhk7' -- 子查询也要限定文档
            AND type = 'i' -- 找到所有绿色的列表项容器
            AND (
                ial LIKE '%background-color: var(--b3-card-info-background)%'
                OR ial LIKE '%background-color: var(--b3-card-success-background)%'
                OR ial LIKE '%background-color: var(--b3-card-warning-background)%'
                OR ial LIKE '%background-color: var(--b3-card-error-background)%'
            )
        )
    )
)
ORDER BY sort ASC
LIMIT 999

SELECT * FROM blocks 
WHERE root_id = '20251210211043-chdub1j' 
AND (
    ial LIKE '%background-color: var(--b3-card-info-background)%'
    OR ial LIKE '%background-color: var(--b3-card-success-background)%'
    OR ial LIKE '%background-color: var(--b3-card-warning-background)%'
    OR ial LIKE '%background-color: var(--b3-card-error-background)%'
)

select * from blocks where path like '%/20250402102311-bhl0ohe%' and (markdown like '%background-color: var(--b3-card-success-background); color: var(--b3-card-success-color);%' or ial like '%background-color: var(--b3-card-success-background); color: var(--b3-card-success-color);%');

以下是测试内容：

信息

成功

无格式信息

警告

错误

• 这是列表块，这句话不想被查询。

  • 这句话标绿，只想要这句话被查询。这句话想被查询。

以下是测试错误截图

其他吐槽：

Ⅰ. 承认失败：查询功能的“伪神性”

我们在前几轮对话中犯了一个错误：试图用 SQL（逻辑语言） 去强行对抗 思源的渲染机制（物理规则） 。

事实证明，思源的 Embed Query (嵌入式查询) 存在致命缺陷：

1. 渲染粒度过粗： 它不懂什么叫“只取一行字”。它只懂“取一个块”。而块往往连带着容器（列表、引述），这导致了你遇到的“株连九族”问题。
2. 自我指涉的黑洞： 它无法优雅地处理“我在查询我自己”的逻辑，导致了死循环。
3. 视觉噪音： 查出来的东西带着原有的格式、圆点、父级背景，这对于追求极致清晰的人 来说，是一坨视觉垃圾。

结论： 如果你的目的是 “动态聚合 Dashboard” （比如把所有标绿的重点自动汇聚成一张表），思源是不及格的。在这个功能上，它连 Logseq 的脚后跟都摸不到。

示例文档如下：↓↓↓↓↓↓↓↓↓

通用测试.sy.zip