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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#816 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 4 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
72/100
Loại issue
Tài liệu
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cassandra, mongodb, postgresql, rust, sqlite
Lĩnh vực
databases, documentation

Hướng nghiên cứu

Thay đổi nằm trong docs/differences-from-dynamodb.md; hãy đọc định dạng bảng hiện có trước. Issue cung cấp các thứ tự đã đo và vị trí scan_impl trong crates/storage-sqlite/src/data/query_scan.rs, crates/storage-mongodb/src/data_engine.rs và crates/storage-cassandra/src/data/scan.rs giải thích chúng, vì vậy hãy xác nhận những vị trí đó trước khi viết. Hoàn thành khi có một hàng mới nêu rằng thứ tự Scan của dịch vụ chưa được tài liệu hóa và không phải thứ tự khóa, rằng SQLite, PostgreSQL và MongoDB dùng thứ tự khóa, còn Cassandra dùng thứ tự token.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
517
Fork
60
Merge trung bình
5 ngày 7 giờ
Pull request đã merge (30 ngày)
64

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ExtendDB/extenddb

Tất cả issue của ExtendDB/extenddb

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.