Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

🚀 [database] Modular `get()` should use the native one-shot read, not `once('value')`

Aperta
#9,344 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, firebase, ios, react-native, typescript

Direzione di ricerca

Start in packages/database/lib/modular/query.ts and trace the NativeRNFBTurboDatabaseQuery entry point described in the proposal. Review the Android, web, and iOS read paths and their documented fallbacks, then verify that plain non-.info locations use the native one-shot read while errors and callers retain once('value') semantics.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What feature would you like to see?

Modular get(query) is implemented as once('value'):

// packages/database/lib/modular/query.ts
export function get(queryRef: Query): Promise<DataSnapshot> {
  return (queryRef as QueryWithSubscriptionMethodsInternal).once("value");
}

On device, once('value') attaches a single-event observer. On the wire that is a listen → data → unlisten exchange: about three server responses per read, and two round trips before the promise settles. The SDKs have a real one-shot read, a single request and response: Android Query.get(), the web SDK's get(), and iOS getDataWithCompletionBlock:.

Why

Realtime Database bills per response as well as per payload byte. We measured with the Admin SDK, which uses the same wire protocol: 500 reads of one leaf each way, with an identical 20.5 KB payload.

responses billed bytes
listen / unlisten (once('value')) ~1,508 ~125 KB
single get (get()) ~513 ~60 KB

That is roughly 129 B less billed per read, and one round trip fewer for every awaited get().

Platform status

  • Android (firebase-database 22.x) and web: the one-shot read is correct for plain locations. It needs once('value') fallbacks in a few cases:
    • Queries: get() parity for unindexed queries is unverified.
    • .info/* paths: the one-shot read goes to the server tree, not the client-local .info tree.
    • Disk persistence on: Query.get() resolves from disk after 3 s, even online.
    • RTDB debug logging on: a get in flight at disconnect is resent only because of a logsDebug()-scoped return.
    • After keepSynced: Query.get() toggles keepSynced on its spec, which cancels the app's own.
  • iOS: not yet. FirebaseDatabase's getData has three bugs, reported upstream with proposed fixes: it returns a covering ancestor's whole node for a child path (firebase/firebase-ios-sdk#12168), never completes a get in flight at disconnect (firebase/firebase-ios-sdk#16717), and crashes on an error reply without a reason (firebase/firebase-ios-sdk#16718). iOS keeps the single-event observer until those ship.

Proposal (PR to follow)

  • Add a native get(app, dbURL, path, modifiers) to NativeRNFBTurboDatabaseQuery:
    • Android: Query.get(), with the native fallbacks above.
    • Web: get().
    • iOS: the single-event observer for now, so the spec is complete and iOS can switch to getData in a one-line follow-up.
  • Modular get() calls it for plain, non-.info locations. A permission denial passes through: Android maps the reply to once's code and message. Any other Android or web failure retries as once('value'), so the error keeps the SDK's code.
  • Callers keep once('value') semantics, with one documented exception. The one-shot read returns the server's reply as it was when the read was sent, so a local write made while a get() is in flight is not in its result. once layered pending writes over the reply, and the web SDK's get() has the same behaviour as this change. This is not a breaking change in any other respect.

🔥

Lingua principale
TypeScript
Stelle
12.3k
Fork
2.3k
Merge medio
3g 6h
PR unite (30g)
39

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di invertase/react-native-firebase

Tutte le issue di invertase/react-native-firebase

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.