[Bug] Store limit dedup emits duplicates on id-only scans because ProjectionStage mutates the stored column
维护者通常 1 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 78/100
调研方向
从 ProjectionStage.java 中的 BACKEND_COLUMN 分支开始，追踪 MapLimitIterator 在仅按 id 执行 PRIMARY_SCAN 且使用 LIMIT_DEDUP 时如何存储和输出列。实现提议的列替换，并添加一个回归测试：在读取下一行之前先投影每个输出行。当逐字节相同的行在投影后仍保持去重时，即表示完成；issue 报告称，不进行该修改时有 100 行，进行修改后有 200 行。
由索引模型根据 Issue 内容生成。
描述
In the review of #3404, @bitflicker64 found that MapLimitIterator keeps each emitted RocksDBSession.BackendColumn in its dedup set and passes the same object downstream. On an id-only PRIMARY_SCAN (null_property = true, no property list, condition, order-by or aggregation) with dedup_option = LIMIT_DEDUP, ProjectionStage.handle() then sets column.value = new byte[0] in place (ProjectionStage.java, the BACKEND_COLUMN branch). The stored key changes after insertion, so it no longer equals a later byte-equal row, and the duplicate is emitted again. Their probe gave 100 rows without the reset and 200 with it.
Only a gRPC client that sets dedup_option reaches this today, since StoreQueryParam fixes it to NONE.
Proposed fix: have ProjectionStage replace the column instead of mutating it (result.setColumn(BackendColumn.of(column.name, new byte[0]))), plus a regression test that runs each emitted row through the projection before reading the next. I'd like to work on this.
- 主要语言
- Java
- 星标
- 3.2k
- 派生
- 642
- 平均合并
- 1 天 11 小时
- 30 天内合并 PR
- 103
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/hugegraph 的其他 Issue
-
[Bug] PD task REST: balanceLeaders throws a bare HTTP 500 during the balance-shard window, and task responses cannot be told apart from a no-op or a follower answer可能已有人在做 @pallavithegod 于 6 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 70/100
apache/hugegraph#3231 · 2 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 55/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
维护者通常 1 天内回复
-
[Bug] PD TTL cleanup deletes the marker-shaped name instead of the expired key, so expired values stay in the store until read可能已有人在做 @bitflicker64 于 5 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 35/100
维护者通常 1 天内回复
-
[Task] Establish systematic performance baselines and optimization tracking可能重新可做 @contrueCT 于 9 天前认领，目前没有进行中的 PR。 未关闭help wanted improvement rust
难度 5/5 一周以上 新手友好度 12/100
apache/hugegraph#3346 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 67/100
-
难度 2/5 1-3 小时 新手友好度 76/100
linagora/twake-calendar-side-service#1218 · 1 条评论 ·
维护者通常 1 天内回复
-
[Bug] [Go] Ack returns nil when the server answers with a non-OK status可能已有人在做 @leizhiyuan 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
apache/rocketmq-clients#1465 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
pdfium-drift
难度 1/5 1 小时以内 新手友好度 88/100
Stirling-Tools/JPDFium#188 ·
维护者通常 1 天内回复