GridDB Python：multi_put 后立即查询为何返回空 RowSet？

2026-11-04数据小许

先修正示例中的参数错误

现有代码无法确认空 RowSet 是否由写入可见性延迟引起，但其中有一处确定的参数错误：datetime.timedelta(ms=i) 应改为 datetime.timedelta(milliseconds=i)。

按照示例代码，Python 会在构造列表时抛出 TypeError，此时 container.multi_put(...) 尚未调用，后续查询也不会执行。如果实际程序打印了 Data found: False，说明运行代码与示例有差异，或外围代码捕获异常后继续执行。

修正代码并确认执行到了哪一步

保留已有的连接和容器创建代码，将写入、查询部分替换为：

now = datetime.datetime.now(datetime.timezone.utc)
rows = [
    [now + datetime.timedelta(milliseconds=i), float(i)]
    for i in range(10)
]

try:
    print(f"Prepared rows: {len(rows)}")
    print(f"Timestamp range: {rows[0][0]} -> {rows[-1][0]}")

    container.multi_put(rows)
    print("multi_put returned without exception")

    query = container.query("select * order by ts desc limit 1")
    row_set = query.fetch()
    print(f"Data found: {row_set.has_next()}")
except Exception:
    import traceback
    traceback.print_exc()
    raise

这段代码有助于区分数据构造失败、写入调用异常、查询执行异常和查询结果为空。multi_put returned without exception 是执行位置标记，不能证明实际写入了多少行。

修正后仍为空时如何排查

核对实际执行代码。确认日志来自本次运行，并检查是否有捕获写入异常后继续查询的逻辑。优先保留完整异常信息。
核对 auto_commit 的设置。问题描述中提到了启用 auto_commit，但示例没有展示设置过程。确认该设置作用于执行写入的 container；如果使用手动提交，应按所用客户端的事务接口完成提交后再查询。
比较查询结果。在同一容器上执行 select *，与原来的排序限量查询对照，记录各自是否有结果。如果只有特定查询为空，再检查该查询在当前环境中的执行情况。
补充版本和时间戳处理信息。记录 GridDB 服务端、Python 客户端和底层依赖版本。示例传入的是带 UTC 时区的 datetime，其支持情况和转换要求需要结合所用客户端确认，不能直接认定这是故障原因。

time.sleep() 应如何看待

增加等待后能查到数据，可以作为复现线索，但还不能证明 multi_put 需要额外等待。现有材料没有提供客户端版本、完整日志或可验证的提交配置，无法据此确定读写一致性方面的原因。

先修复 milliseconds 参数，再用同一份代码记录不等待和等待两种情况下的结果。若问题仍能稳定复现，应根据这些日志继续判断原因，避免把固定等待时间作为最终修复。