🚀 [database] Modular `get()` should use the native one-shot read, not `once('value')`
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
- Ambito
- database, mobile-dev
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.infotree.- 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()-scopedreturn. - After
keepSynced:Query.get()toggleskeepSyncedon its spec, which cancels the app's own.
- Queries:
- iOS: not yet. FirebaseDatabase's
getDatahas 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)toNativeRNFBTurboDatabaseQuery:- 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
getDatain a one-line follow-up.
- Android:
- Modular
get()calls it for plain, non-.infolocations. A permission denial passes through: Android maps the reply toonce's code and message. Any other Android or web failure retries asonce('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 aget()is in flight is not in its result.oncelayered pending writes over the reply, and the web SDK'sget()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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di invertase/react-native-firebase
-
Needs Attention platform: ios plugin: app-core plugin: storage type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
invertase/react-native-firebase#9342 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[messaging][ios] APNs token type is inferred from DEBUG instead of the signed APNs environmentApertaNeeds Attention type: bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 56/100
invertase/react-native-firebase#9348 ·
I maintainer di solito rispondono entro 1 giorno
-
platform: ios plugin: database type: bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 78/100
invertase/react-native-firebase#9339 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
blocked: customer-response platform: android plugin: app-check Stale type: bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
invertase/react-native-firebase#9227 · 7 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
blocked: firebase-sdk Keep Open plugin: analytics type: bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
invertase/react-native-firebase#9115 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di invertase/react-native-firebase
Issue simili
-
priority: P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
prime-radiant-inc/evener#3291 ·
I maintainer di solito rispondono entro 1 giorno
-
accessibility bug revealjs
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
quarto-dev/quarto-cli#14961 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
supabase/agent-skills#614 ·
-
Content
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
RunestoneInteractive/rs#1559 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni