In che modo differisce esattamente fetchAllIfNeeded da fetchAll nel JS SDK?

Question

Non ho mai capito del tutto la se necessario parte della descrizione.

.fetchAll() Rileva l'elenco specificato di Parse.Object.

.fetchAllIfNeeded() recupera la lista data di Parse.Object se necessario.

Qual è la situazione in cui posso utilizzare questo e cosa determina esattamente la necessità? Sento che è qualcosa di super elementare, ma non sono stato in grado di trovare una definizione soddisfacente e chiara.

Nell'esempio nell'API, ho notato che il fetchAllIfNeeded() ha:

// Objects were fetched and updated. 

nel successo mentre il fetchAll deve solo:

// All the objects were fetched. 

così fa il fetchAllIfNeeded() anche salvare roba troppo? Molto confuso qui.

AGGIORNAMENTI

TEST 1

Andando su alcuni dei suggerimenti @danh lasciati nei commenti ho provato le seguenti cose.

var todos = []; 
var x = new Todo({content:'Test A'}); // Parse.Object 
todos.push(x); 
x.save(); 

// So now we have a todo saved to parse and x has an id. Async assumed. 

x.set({content:'Test B'}); 

Parse.Object.fetchAllIfNeeded(todos); 

Quindi, in questo scenario, il mio cliente x è diverso da quello del server. Ma lo x.hasChanged() è falso poiché abbiamo utilizzato la funzione set e l'evento di modifica è stato attivato. fetchAllIfNeeded non restituisce risultati. Quindi non è che stia cercando di confrontare questo a titolo definitivo con ciò che è sul server per sincronizzare e recuperare.

Mi accorgo che nel carico utile della richiesta, l'esecuzione del fetchAllIfNeeded sta inviando la seguente cosa interessante.

{where: {objectId: {$in: []}}, _method: "GET",…} 

così sembra che sul lato client qualcosa determina se un oggetto deve sempre essere presente

Test 2

Così ora, sulla base dei commenti che ho provato manipolare la changed stato dell'oggetto impostando con silenzioso.

x.set({content:'Test C'}, {silent:true}); 
x.hasChanged(); // true 
Parse.Object.fetchAllIfNeeded(todos); 

Ancora niente di interessante. Chiaramente lo stato del server ("Test A") è diverso da clientide ("Test C"). e ho ancora i risultati [] e la richiesta di carico utile è:

{where: {objectId: {$in: []}}, _method: "GET",…} 

UPDATE 2

capito, cercando alla fonte Parse. Vedi la risposta.

Answer 1

Dopo molte manipolazioni, quindi dando un'occhiata alla fonte, l'ho capito. Fondamentalmente lo fetchAllIfNeeded preleverà i modelli in una matrice che non ha dati, il che significa che non ci sono proprietà e valori degli attributi.

Quindi il caso d'uso sarebbe se si lascia dire un oggetto genitore con una matrice di oggetti di analisi annidati. Quando si recupera l'oggetto padre, gli oggetti figlio nidificati nell'array non verranno inclusi (a meno che non si disponga del set di vincoli di query include). Invece, i puntatori vengono inviati al client e nel client, quei puntatori vengono tradotti in modelli "vuoti" senza dati, in pratica solo Parse.Objects con id.

In particolare, Parse.Object ha una proprietà booleana interna denominata _hasData che sembra essere attivata in qualsiasi momento, come set, o fetch, o qualsiasi altra cosa dia gli attributi di quel modello.

Quindi, diciamo che è necessario recuperare quegli oggetti figlio. Puoi fare qualcosa come

var childObjects = parent.get('children'); // Array 
Parse.Object.fetchAllIfNeeded(childObjects); 

E cercherà quei bambini che attualmente sono rappresentati solo come oggetti vuoti con id.

È utile a differenza di fetchAll in quanto si può passare attraverso l'array di bambini e caricarlo lentamente uno alla volta, se necessario, quindi in un secondo momento è necessario "ottenere il resto". fetchAllIfNeeded essenzialmente filtra "il resto" e invia una query whereIn che limita il recupero a quegli oggetti figlio che non hanno dati.

Nella documentazione Parse, hanno un commento nella risposta callback fetchAllIfNeeded come:

// Objects were fetched and UPDATED. 

penso che significano gli oggetti lato client sono stati aggiornati. fetchAllIfNeeded invia definitivamente le chiamate GET, quindi dubito degli aggiornamenti sul lato server. Quindi questa non è una funzione di sincronizzazione. Questo mi ha davvero confuso come ho subito pensato di aggiornamento lato server quando realmente significano:

// Client objects were fetched and updated.