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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#816 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cassandra, mongodb, postgresql, rust, sqlite
Área
databases, documentation

Línea de trabajo

El cambio va en docs/differences-from-dynamodb.md; lee primero el formato de tabla existente. El issue indica los órdenes medidos y las ubicaciones de scan_impl en crates/storage-sqlite/src/data/query_scan.rs, crates/storage-mongodb/src/data_engine.rs y crates/storage-cassandra/src/data/scan.rs que los explican, así que confírmalas antes de escribir. Está terminado cuando hay una nueva fila que indica que el orden de Scan del servicio no está documentado y no es el orden de claves, que SQLite, PostgreSQL y MongoDB usan el orden de claves y que Cassandra usa el orden de tokens.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
517
Forks
60
Merge medio
5 d 7 h
PR fusionados (30 d)
64

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ExtendDB/extenddb

Todos los issues de ExtendDB/extenddb

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.