Skip to main content
只问一次;HeavenBase 会路由问题,但仍希望你亲手打开答案。

1. 动机

应用代码应该描述数据意图,而不是选择 Provider 客户端或合并算法。 HeavenBase Query 是不可变请求值,由工作区结合 Entity schema、放置规则、Backend、handler 与 Context 策略进行解析。 构造过程不执行 I/O。 只有 execute()explain() 会跨越路由边界。

2. 构建不可变查询

每次变换都会返回新的 hb.Query;这里没有可变的 QueryBuilder。 请像上面的 basenearest 一样,用普通赋值创建分支。 to_spec() 返回路由使用的结构化不可变请求。 它不会选择 Backend,也不会执行 I/O。

3. 读取 ResultFrame

每次 execute() 都会重新计算并返回一个新的 detached hb.ResultFrame。 结果不会被自动缓存或持久化。
请使用 rows()scalar()to_pandas()to_pyarrow()to_numpy()to_pydantic()to_daft() 等显式出口。 Frame 变换返回新 frame,访问器则返回由调用方拥有的值。 投影后仍保留 object_id,因此紧凑结果依然可以驱动后续 getsetdelete 调用。

4. 过滤与搜索

字段引用会构建类型化表达式,并通过 &|~ 组合。
contained_in(...) 执行反向包含:它询问哪些已存短值出现在更长的查询字符串中。 对于 Array[ShortText],SQL Backend 会在可用时使用 SparseGramIndex,并在保留的 match 元数据列中保存匹配关键词证据。 当无法证明 Provider 原生语义时,文本操作可能使用可移植 scan。 在用查询级 .unsafe() 以可移植性换取速度前,请先检查执行计划。

5. 接受 JSON 查询

query_json 会验证可序列化请求,并将其降低为同一个不可变 Query 值。
支持的顶层子句包括 filteravailableneartraverseselectgroup_byaggregatehavingorderoffsetlimitunsafe。 未知或过时的键会失败,而不会被忽略。 where() 也接受 Mongo 风格过滤映射,可使用 $eq$in$match$contained_in$array_contains 等已注册操作符。

6. 计数与聚合

count() 是仅针对数据源的终结 Query 规格。 它之前只能出现数据源过滤、搜索、遍历与 unsafe 策略。
分组聚合使用字段 metric 表达式:
请在 aggregate(...) 后使用 having(...),并使用 order_by(...) 对结果排序。 路由可能执行 Provider 原生聚合或精确可移植 fold;explain() 会告诉你实际选择。

7. 检查执行计划

执行计划报告存储放置、选中的 Backend、策略、handler 类型、执行模式、可移植性证明以及 fallback 或 unsupported 原因。 已安装操作或匹配标签本身并不能证明原生执行。

8. 让写入留在 Query 之外

Query 负责读取。 工作区 CRUD 拥有变更:
当一个 object id 可能存在于多个 Entity 类型下时,请传入 entity=...

总结

  • Query 值不可变且惰性执行。
  • 每次执行都会返回新的 detached ResultFrame。
  • Python 与 JSON 表面共享同一个经过验证的请求模型。
  • Explain 输出是实际路由行为的权威。

进一步探索

相关资源: