REST /v1/objects totalResults 返回的结果是页面大小,而不是总数,这与 OpenAPI 规范相矛盾

□ 总结

GET /v1/objects'将总结果'设定为它刚刚返回的一页中的对象数量,因此它总是等于`限制'(或最后一页中剩余的对象数量)。 OpenAPI spec 承诺相反.

`openapi-specs/schema.json:3494':

`总结果':"总查询对象数. 响应中的项目数量可能因呼出而更小".

`适应器/手/手/手/手-物体',两个反应站点:

开始 / / : 279 (列表路径) 总结果:int64(len(名单)),

// : 340( 平滑路径) 总结果: int64(len(成果套)),

`len(list)'为一页。 spec's自有的句子——"一个响应中的项目数量可能由于呼号而更小"——只有当'total Results'是这个数字以外的东西时才有意义,而从没有.

□再现.

任何对象超过限制的集合 。 针对318项对象收集:

获取/v1/objects? class=FirstJobsVector & Limit=1 - > 总结果=1 获取/v1/对象? class=FirstJobsVector & Limit=5 - > 总结果=5 获取/v1/objects? class=FirstJobsVector & Limit=100 - > 总结果=100

按类别分列:所有三种情况下的 " 318 " 。

于1.39.4(WCD, Europe-west3)验证. 代码在 " main " 上没有变化, " git log -S " 显示两行最近没有变化,因此这是长期的,而不是倒退。

∮为什么它很重要∮

球场是REST对象 API 提议中唯一一个 pagination , 它对此无法使用——沉默地。 它从来不会出错,而且值总是看起来很合理,所以一个客户端计算页面数或者从中抵消一个采样得到一个看起来正确的错误答案.

具体来说,这个咬了我们自己的SRE工具. 矢量-索引修复从随机偏移中抽取的对象,以避免总是检测相同的对象:

开始
总计,  : = cl. Count Objects(ctx, 收集, 租户) // 读取总计 Results
页:1
如果 int( 总数) > sampleSize { // 总是虚假的: 总 == 1
页:1 INTN( int( 总) - 样本大小)
{\fn黑体\fs22\bord1\shad0\3aHBE\4aH00\fscx67\fscy66\2cHFFFFFF\3cH808080}你觉得呢?

总'总是1',所以抵消'总是0',核查员在每次运行时都调查同一收集的负责人——它自己的评论中准确的失败说,抵消是存在的以防止的。 它没有受到注意,因为单位测试用"总结果":4321'使HTTP反应被打出"而从未锻炼出真正的语义".

任何客户端从这个字段算出 都有相同的潜在错误

□ 可能的决议

列出来讨论,而不是作为偏好——成本/相匹配取舍是自有团队的号召.

1. ** 使其成为实际总数。 ** 匹配规格。 对于分级的路径,硬质物体计算Weaviate已经维持(被/v1/nodes?outputs=verbose'和AggregateobjectsCount'使用)应使这种价格更低;未过滤的跨类清单更难。 这是任何依赖今天价值的人的行为改变.
2. ** 校正谱**,以描述代码的作用。 零风险,但留下 REST pagignation 没有 . . . . . . .