Google Firestore - jak uzyskać dokument za pomocą wielu identyfikatorów w jednej podróży w obie strony?

Zastanawiam się, czy możliwe jest pobranie wielu dokumentów według listy identyfikatorów w jednej podróży w obie strony (połączenie sieciowe) do Firestore.

jeśli jesteś w Node:

https://github.com/googleapis/nodejs-firestore/blob/master/dev/src/index.ts#L701

/**
* Retrieves multiple documents from Firestore.
*
* @param {...DocumentReference} documents - The document references
* to receive.
* @returns {Promise<Array.<DocumentSnapshot>>} A Promise that
* contains an array with the resulting document snapshots.
*
* @example
* let documentRef1 = firestore.doc('col/doc1');
* let documentRef2 = firestore.doc('col/doc2');
*
* firestore.getAll(documentRef1, documentRef2).then(docs => {
*   console.log(`First document: ${JSON.stringify(docs[0])}`);
*   console.log(`Second document: ${JSON.stringify(docs[1])}`);
* });
*/

Dotyczy to szczególnie zestawu SDK serwera

AKTUALIZACJA: „Cloud Firestore [sdk po stronie klienta] obsługuje teraz zapytania!”

https://firebase.googleblog.com/2019/11/cloud-firestore-now-supports-in-queries.html

myCollection.where(firestore.FieldPath.documentId(), 'in', ["123","456","789"])

Właśnie ogłosili tę funkcję, https://firebase.googleblog.com/2019/11/cloud-firestore-now-supports-in-queries.html .

Teraz możesz używać zapytań takich jak, ale pamiętaj, że rozmiar wejściowy nie może być większy niż 10.

userCollection.where('uid', 'in', ["1231","222","2131"])

Nie, w tej chwili nie ma możliwości grupowania wielu żądań odczytu za pomocą pakietu SDK Cloud Firestore, a zatem nie ma możliwości zagwarantowania, że ​​można odczytać wszystkie dane naraz.

Jednak, jak powiedział Frank van Puffelen w komentarzach powyżej, nie oznacza to, że pobranie 3 dokumentów będzie 3x wolniejsze niż pobranie jednego dokumentu. Najlepiej jest wykonać własne pomiary przed wyciągnięciem wniosków.

W praktyce użyłbyś firestore.getAll w ten sposób

async getUsers({userIds}) {
    const refs = userIds.map(id => this.firestore.doc(`users/${id}`))
    const users = await this.firestore.getAll(...refs)
    console.log(users.map(doc => doc.data()))
}

lub ze składnią obietnicy

getUsers({userIds}) {
    const refs = userIds.map(id => this.firestore.doc(`users/${id}`))
    this.firestore.getAll(...refs).then(users => console.log(users.map(doc => doc.data())))
}

Możesz użyć takiej funkcji:

function getById (path, ids) {
  return firestore.getAll(
    [].concat(ids).map(id => firestore.doc(`${path}/${id}`))
  )
}

Można go wywołać za pomocą jednego identyfikatora:

getById('collection', 'some_id')

lub tablica identyfikatorów:

getById('collection', ['some_id', 'some_other_id'])

Z pewnością najlepszym sposobem na to jest zaimplementowanie rzeczywistego zapytania Firestore w funkcji chmury? Byłoby wtedy tylko jedno połączenie w obie strony od klienta do Firebase, o które wydaje się, że właśnie o to prosisz.

Naprawdę chcesz i tak zachować całą logikę dostępu do danych, taką jak ta po stronie serwera.

Wewnętrznie prawdopodobnie będzie taka sama liczba połączeń z samym Firebase, ale wszystkie będą realizowane przez superszybkie połączenia międzysieciowe Google, a nie przez sieć zewnętrzną, aw połączeniu z potokami, które wyjaśnił Frank van Puffelen, powinieneś uzyskać doskonałą wydajność od to podejście.

Jeśli używasz trzepotania, możesz wykonać następujące czynności:

Firestore.instance.collection('your collection name').where(FieldPath.documentId, whereIn:[list containing multiple document IDs]).getDocuments();

To zwróci Przyszłość, List<DocumentSnapshot>którą możesz iterować według własnego uznania.

Oto jak zrobiłbyś coś takiego w Kotlin z Android SDK.
Może niekoniecznie odbywać się w jednej podróży w obie strony, ale skutecznie grupuje wynik i pozwala uniknąć wielu zagnieżdżonych wywołań zwrotnych.

val userIds = listOf("123", "456")
val userTasks = userIds.map { firestore.document("users/${it!!}").get() }

Tasks.whenAllSuccess<DocumentSnapshot>(userTasks).addOnSuccessListener { documentList ->
    //Do what you need to with the document list
}

Pamiętaj, że pobieranie określonych dokumentów jest znacznie lepsze niż pobieranie wszystkich dokumentów i filtrowanie wyników. Dzieje się tak, ponieważ Firestore pobiera opłaty za zestaw wyników zapytania.

Mam nadzieję, że to ci pomoże, działa na mnie.

getCartGoodsData(id) {

    const goodsIDs: string[] = [];

    return new Promise((resolve) => {
      this.fs.firestore.collection(`users/${id}/cart`).get()
        .then(querySnapshot => {
          querySnapshot.forEach(doc => {
            goodsIDs.push(doc.id);
          });

          const getDocs = goodsIDs.map((id: string) => {
            return this.fs.firestore.collection('goods').doc(id).get()
              .then((docData) => {
                return docData.data();
              });
          });

          Promise.all(getDocs).then((goods: Goods[]) => {
            resolve(goods);
          });
        });
    });
  }

W tej chwili nie wydaje się to możliwe w Firestore. Nie rozumiem, dlaczego odpowiedź Aleksandra została przyjęta, rozwiązanie, które proponuje, zwraca po prostu wszystkie dokumenty z kolekcji „użytkownicy”.

W zależności od tego, co musisz zrobić, powinieneś rozważyć powielenie odpowiednich danych, które chcesz wyświetlić, i zażądać pełnego dokumentu tylko wtedy, gdy jest to konieczne.

Najlepsze, co możesz zrobić, to nie używać go Promise.alljako klienta, a następnie musi czekać.all odczyt przed kontynuowaniem.

Powtarzaj odczyty i pozwól im rozwiązać się niezależnie. Po stronie klienta prawdopodobnie sprowadza się to do tego, że interfejs użytkownika ma kilka obrazów programu ładującego postęp, które są przetwarzane na wartości niezależnie. Jest to jednak lepsze niż zamrażanie całego klienta do.all czasu rozwiązania odczytów.

Dlatego natychmiast zrzuć wszystkie synchroniczne wyniki do widoku, a następnie pozwól, aby asynchroniczne wyniki pojawiały się indywidualnie, gdy zostaną rozwiązane. Może się to wydawać drobnym rozróżnieniem, ale jeśli twój klient ma słabą łączność z Internetem (tak jak ja mam obecnie w tej kawiarni), zamrożenie całego doświadczenia klienta na kilka sekund prawdopodobnie spowoduje, że `` ta aplikacja jest do bani ''.