Firebase child_added senza caricare prima tutti i dati

Question

Ho un'applicazione in cui voglio caricare una certa quantità di dati iniziali (eseguita con Firebase.once('value')) e poi a un certo punto più avanti mi piacerebbe ricevere gli eventi di nodi figli che sono stati aggiunti a quel riferimento Firebase.

Per questo, mi piacerebbe utilizzare Firebase.on('child_added'), ma secondo la definizione (e visto in pratica) carica TUTTI i dati a quel riferimento Firebase prima.

C'è un modo per aggirare questo comportamento e ascoltare solo gli eventi child_added. Inoltre, soluzioni alternative come il dumping del set iniziale di dati non sono soluzioni (si immagini un set di dati con oltre un milione di punti dati - non voglio avere in ogni punto dati solo per ascoltarlo quando ne viene aggiunto uno!).

MODIFICA: Firebase.on('child_added') può essere combinato con limit() per limitare la quantità di dati proveniente dalla richiesta iniziale. Probabilmente per la mia applicazione, solo un punto dati verrà aggiunto al Firebase in un determinato momento, quindi ho utilizzato Firebase.limit(1).on('child_added') che limita la quantità di dati iniziali caricati in un singolo punto dati. Ma non mi piace questa soluzione alternativa per due motivi:

1. È ancora una soluzione alternativa. Devo ancora ignorare i dati che non dovrei preoccuparmi di ignorare.
2. Se per qualche motivo la natura della mia domanda dovesse cambiare e dovessi aggiungere più bambini al riferimento Firebase in una volta, imporre un limite di limit(1) alla ricezione di tutti i child aggiunti? Non sono sicuro che sia così o se child_added venga chiamato per ogni singolo figlio aggiunto, indipendentemente dal fatto che siano stati aggiunti come batch.

Sembra che fornisce una bandiera true/false come argomento per la chiamata sarebbe una bella soluzione, ma io aspettare per vedere se c'è una risposta che ho sorvolare ...

Answer 1

cancella vecchi messaggi

Se non sei interessato ai dati storici, lo stai utilizzando come coda di messaggi. In questo caso, i vecchi record dovrebbero essere cancellati (o archiviati in un percorso alternativo) dopo averli letti. In questo modo, il problema si risolve da solo.

Se si desidera mantenere questo modello, sono disponibili un paio di buone opzioni:

negozio l'ultima lettura chiave e utilizzarlo come punto di partenza del tuo prossimo carico

Si potrebbe anche archiviare il chiave nel Firebase

var fb = new Firebase(URL); 
fb.child('last_read_key').once('value', function(lastReadSnap) { 
    var lastKey = lastReadSnap.val(); 
    var pri = lastReadSnap.getPriority(); 
    fb.child('data_to_read').startAt(pri, lastKey).on('child_added', function(snap) { 
     if(snap.name() !== lastKey) { 
     console.log('new record', snap.name()); 
     fb.child('last_read_key').setWithPriority(snap.name(), snap.getPriority()); 
     } 
    }); 
}); 

Utilizzare le priorità per contrassegnare timestamp di vecchi dischi

record Durante la scrittura, l'uso setWithPriority:

fb.child('records/$recordid').setWithPriority(data, Firebase.ServerValue.TIMESTAMP); 

Ora si può leggere dischi a partire da "ora":

fb.child('records').startAt(Date.now()).on('child_added', function(snap) { 
    console.log('new child', snap.name()); 
}); 

nota un avvertimento di usare timestamp qui. Ho usato la data.now() nel comando startAt(), perché attualmente non supporta Firebase.ServerValue.TIMESTAMP (bug archiviato per questo).