Solución:
ACTUALIZACIÓN 2020-01-23:
Para obtener actualizaciones sobre esto, consulte una conversación con Sam Stern en el tablero del grupo: https: //groups.google.com/d/msgid/google-cloud-firestore-discuss/e1b47358-b106-43a0-91fb-83c97d6244de%40googlegroups. com
Gran parte de la discusión proviene del hecho aparente de que hay un ÚNICO “índice maestro” de TODOS los registros en una base de datos basado en la ruta TOTALMENTE CALIFICADA al documento (por lo tanto, solo necesita ser único “dentro de una colección”).
Para “acelerar” las referencias de documentos, el SDK de JS en realidad “antepone” la ruta de la colección a cualquier información que se pase en .doc para usar “convenientemente” ese índice maestro.
es decir, todos estos son exactamente equivalentes
db.doc('collection/docId/collection/docId/collection/docId")
db.collection('collection").doc("docId/collection/docId/collection/docId")
db.collection('collection").doc("docId").collection("collection").doc("docId/collection/docId")
db.collection('collection").doc("docId").collection("collection").doc("docId").collection("collection").doc("docId")
db.doc("collection/docId").collection("collection").doc("docId").collection("collection").doc("docId")
db.collection("collection/docId/collection").doc("docId").collection("collection").doc("docId")
db.doc("collection/docId/collection/docId").collection("collection").doc("docId")
db.collection("collection/docId/collection/docId/collection").doc("docId")
— TODOS crean la misma referencia de índice ‘collection / docId / collection / docId / collection / docId “para encontrar el documento en el” índice maestro “.
(en mi opinión nada humilde) FieldPath.documentId () se implementó (incorrectamente) para que coincida “convenientemente” con este comportamiento, por lo que se requiere la ruta completamente calificada, no el docId, cuando deberían se implementaron como cualquier otra consulta y requirieron la creación y mantenimiento de un NUEVO ÍNDICE para acomodar la consulta.
El código para este comportamiento se escribió ANTES de que se implementaran los grupos de colección, y nunca se documentó que el truco utilizado no coincidiera con el NOMBRE DEL MÉTODO utilizado.
La solución es requerir que el codificador copie el docId como un campo en cada documento y escriba sus consultas sobre eso. Ya escribí mi propia capa entre Firestore.js y mi aplicación para abstraer el comportamiento, y probablemente simplemente implemente esto como una característica básica de la biblioteca.
Pero esto es claramente un ERROR, y hasta ahora todo el mundo sigue intentando decirme que tiene sentido y que cambiarán la documentación para que coincida con el comportamiento existente (pero no con el nombre del método).
Como escribí anteriormente, me siguen entregando un andrajoso ramo de margaritas, y me dicen “¿Ves? ¡Son rosas! ¡La documentación las llama rosas! ¡Las rosas con cualquier otro nombre huelen tan dulcemente, y todo eso!”
No se esperan actualizaciones a menos que se avergüencen lo suficiente
ACTUALIZACIÓN 2020-01-10: He creado una aplicación de demostración que muestra el error exacto y la he enviado al soporte de Firebase según lo solicitado. Por alguna maldita razón, la criatura de soporte lo considera una “solicitud de función”, a pesar de que claramente es un error. Cuando se llama a una URL con el formato “/ ShowInfo / showID”, la aplicación inicia sesión en Firebase Auth de forma anónima; luego llama a una consulta en collectionGroup (3 niveles de profundidad) usando FieldPath.documentId () “==” showID
Realiza la consulta de 3 formas:
1) Una vez con solo el showID, que falla con la conocida “Consulta no válida. Al consultar un grupo de colección mediante FieldPath.documentId (), el valor proporcionado debe dar como resultado una ruta de documento válida, pero ‘pqIPV5I7UWne9QjQMm72’ (el showID real) es no porque tenga un número impar de segmentos (1) “.
2) Una vez con una “Ruta relativa” (/ Shows / showID), que no tiene el error, pero no devuelve ningún documento.
3) Finalmente con la “Ruta completa” (/ Artists / ArtistID / Tour / tourID / Shows / showID). Esto no tiene un error y lo hace devolver un documento, pero si tengo la ruta completa, ¿por qué necesito la consulta en el grupo de colección? Y yo no tener la ruta completa – el showID (arriba) viene como parte de una URL (un enlace a los datos del programa, obviamente) – lo falsifiqué a mano para la prueba.
Esperando una respuesta.
ACTUALIZACIÓN 2019-12-02: El soporte de Firebase se comunicó para preguntar si todavía quería que esto se resolviera. Duh.
ACTUALIZACIÓN 2019-09-27: Firebase Support ha reconocido que se trata de un error. No se sabe cuándo se solucionará. documentId () deberían, de hecho, poder ser utilizado directamente contra solamente el documento Id.
documentID pueden puede usarse como parte de una consulta pero, como @ greg-ennis señala arriba, necesita un número par de segmentos. Como resulta, si realmente necesita un grupo de colección (yo sí), entonces el “Id” que se va a comparar debe excesivamente agregue el ID / nombre del grupo de colección como un segmento:
db.collectionGroup('likedBy')
.where(firebase.firestore.FieldPath.documentId(), '==', "likedBy" + "https://foroayuda.es/" + "User A")
.get();
Lo he usado y (* sorta) funciona. (es cierto que me tomó 2 horas resolverlo, y la pregunta anterior ayudó a enfocar la búsqueda)
Por otra parte, esta caso específico es no donde desea utilizar collectionGroup. Recuerda que grupo de colección es – una forma de referirse a un conjunto de colecciones separadas como si fueran uno. En este caso, la “colección” que contiene los Me gusta del “Usuario A” existe como una colección en el documento del “Usuario A”. Simplemente elimine ese colección única antes de eliminar el documento del “Usuario A”. No es necesario incluir los gustos de todos los demás.
Sorta: la ruta del campo comparada aparentemente tiene que ser la completo ruta al documento. Si conoce el ID del documento, pero por “razones” no conoce el camino completo, incluso de qué documento forma parte la subcolección (algo así como por qué estaba utilizando el enfoque collectionGroup en primer lugar), ahora parece un callejón sin salida. Continuar trabajando en ello.
Informe verificado y de error archivado: FieldPath.documentID () no no comparar con documentId; se compara con la ruta del documento completamente segmentada, exactamente como tendría que proporcionar a .doc (ruta):
A saber: para encontrar un documento en “TopCollection / document_this / NextCollection / document_that / Travesty / document_Id_I_want”
usando el grupo collectionGroup “Travesty”
db.collectionGroup("Travesty")
.where(firebase.firestore.FieldPath.documentId(), '==', "document_id_I_want")
…voluntad fallar, pero …
db.collectionGroup("Travesty")
.where(firebase.firestore.FieldPath.documentId(), '==', "TopCollection/document_this/NextCollection/document_that/Travesty/document_Id_I_want")
.get()
…voluntad triunfar. Lo que hace que esto sea inútil, ya que si tuviéramos todos ese info, solo usaríamos:
db.doc("TopCollection/document_this/NextCollection/document_that/Travesty/document_Id_I_want")
.get()
No hay forma de que pueda utilizar la siguiente consulta:
db.collectionGroup('likedBy').where(firebase.firestore.FieldPath.documentId(), '==', "User A").get();
Y esto se debe a que las consultas de grupos de colecciones solo funcionan en las propiedades del documento y no en ID de documento. Según la documentación oficial sobre consultas de grupos de cobranza:
db.collectionGroup('landmarks').where('type', '==', 'museum');
Consultas el landmarks subcolección donde el type la propiedad tiene el valor de museum.
Una solución alternativa podría ser almacenar la identificación del usuario en una matriz y usar array-contains pero recuerde, para cada consulta de grupo de colección que use, necesita un índice y, desafortunadamente, no puede crear dicho índice mediante programación. Incluso si puede crear un índice en la consola de Firebase, no lo ayudará ya que obtiene esos identificadores de forma dinámica. Por lo tanto, no es una opción crear un índice para cada usuario por separado porque alcanzará el número máximo de índices muy rápidamente.
Número máximo de índices compuestos para una base de datos: 200
Para resolver este tipo de problemas, debe considerar agregar una matriz debajo de cada objeto de usuario y usar una consulta como esta:
usersRef.where("usersWhoLikedMe", "array-contains", "someUserId")
Dónde usersWhoLikedMe es una propiedad de tipo matriz.