docs: Scan returns items in key order on SQLite and MongoDB and in token order on Cassandra; the service returns them in another order

オープン 初心者向け
  • 何か問題がありますか？
#816 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 4 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
cassandra, mongodb, postgresql, rust, sqlite
領域
databases, documentation

調査の方向性

変更は docs/differences-from-dynamodb.md に加えてください。まず既存の表の形式を確認してください。Issue には計測された順序と、それを説明する crates/storage-sqlite/src/data/query_scan.rs、crates/storage-mongodb/src/data_engine.rs、crates/storage-cassandra/src/data/scan.rs 内の scan_impl の場所が記載されています。書く前にそれらを確認してください。完了条件は、サービスの Scan の順序が文書化されておらず、キー順ではないこと、SQLite、PostgreSQL、MongoDB はキー順を使い、Cassandra はトークン順を使うことを述べた新しい行が1つ追加されていることです。

索引モデルが issue の本文から書いたものです。

説明

A Scan returns a table's items in a different order on the service and on each ExtendDB backend. SQLite and MongoDB return them in primary key order. Cassandra returns them in the token order of the partition key. The service returns them in an order that is neither: in the three tables measured, the partition key values a to f came back in the same relative order (f, b, c, d, e, a), with the items of one partition in sort key order. The service does not document a Scan order, and docs/differences-from-dynamodb.md does not list this difference, so a test or application written against one backend can depend on an order the service and the other backends do not give.

Measured against Amazon DynamoDB in us-east-1 on 2 November 2026, one request per page. Three tables with pk S HASH and sk S RANGE; every item has sk x except a/y. Each Scan runs with Limit 1 and follows LastEvaluatedKey to the end. ExtendDB answers are from main eaf16e89e (debug builds); SQLite and MongoDB without Limit give the same order.

Request DynamoDB ExtendDB main eaf16e89e, SQLite and MongoDB ExtendDB main eaf16e89e, Cassandra
Scan, items a/x, a/y, b/x, c/x, d/x b/x, c/x, d/x, a/x, a/y a/x, a/y, b/x, c/x, d/x a/x, a/y, c/x, d/x, b/x
Scan, items a/x, a/y, b/x, c/x b/x, c/x, a/x, a/y a/x, a/y, b/x, c/x a/x, a/y, c/x, b/x
Scan, items a/x to f/x f/x, b/x, c/x, d/x, e/x, a/x a/x to f/x in key order a/x, c/x, f/x, e/x, d/x, b/x

On every target each page held one item with a LastEvaluatedKey, and the Scan ended with one empty page.

Where the order comes from

  • SQLite: scan_impl orders a base table by pk and the sort key column (crates/storage-sqlite/src/data/query_scan.rs, lines 294 to 297).
  • MongoDB: scan_impl sorts a base table by _id (crates/storage-mongodb/src/data_engine.rs, line 1561).
  • Cassandra: scan_impl walks the token ring of the partition key and continues with token(pk) > token(?) (crates/storage-cassandra/src/data/scan.rs, the module comment at lines 10 to 30 and the query at line 390).
  • PostgreSQL orders by key in scan_impl (crates/storage-postgres/src/data/query_scan.rs, line 379); it was not measured in this pass.

Proposal

Add a row to docs/differences-from-dynamodb.md: the service returns Scan items in an order that is not the key order and that it does not document; SQLite, PostgreSQL and MongoDB return key order and Cassandra returns token order, so no backend gives the service's order and Cassandra's differs from the others. The measured order is not the byte order of the key values either, so this issue proposes a documentation change only.

Not measured

Larger tables, where the service's order may also depend on how it splits the table; parallel Scans with Segment and TotalSegments; Scans of secondary indexes; PostgreSQL.

Related

#425 covers the order of LSI Query items that share an index sort key on the SQL backends.

主要言語
Rust
スター
517
フォーク
60
平均マージ
5日 7時間
マージ済み PR（30日）
64

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ExtendDB/extenddb のほかの issue

ExtendDB/extenddb の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。