Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

perf: add a bounded paged query cursor

Abierto
  • ¿Algo no está bien?
#399 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
cpp, javascript, react-native, sqlite
Área
databases, mobile-dev, performance

Línea de trabajo

Start by locating the eager query implementation and the prepared-statement and connection lifecycle code, then read related issues #30, #62, and #389. Define the cursor ownership and cleanup behavior before implementing it. Done means bounded paging, explicit close, the listed lifecycle and concurrency tests, WAL cleanup documentation, and a large-result time-to-first-page and memory comparison.

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

Descripción

area:api area:runtime enhancement

Ordinary queries step every row and retain the complete result before returning it. Large SELECTs can hold the native result and its JavaScript conversion at once, so a caller that processes rows in batches still pays for the full result. The positional storage in #389 lowers per-row overhead but does not bound the number of retained rows.

Add an opt-in asynchronous cursor that returns a limited page of rows per request and continues stepping the same prepared statement on demand. Give callers an explicit close operation; finalization on garbage collection should be a fallback. The cursor must own its connection and statement safely across queued work, close, errors, and transaction completion. Define whether it uses a dedicated independent read connection or blocks other work on its connection while active.

Test early close, an empty result, page boundaries, metadata, BLOB lifetime, concurrent writes, and close with a page request pending. An open SQLite reader can hold a WAL snapshot and delay checkpoints, so document that cost and verify cleanup. Compare time to first page and peak memory with the eager API on a large result. Application code can use bounded keyset queries today; this issue is for a library-managed cursor.

Related: #30, #62, #389.

Lenguaje dominante
C
Estrellas
579
Forks
53
Merge medio
2 d 3 h
PR fusionados (30 d)
70

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 margelo/react-native-nitro-sqlite

Todos los issues de margelo/react-native-nitro-sqlite

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.