{"componentChunkName":"component---src-templates-blog-post-js","path":"/campos-unicos-en-firestore/","result":{"data":{"site":{"siteMetadata":{"title":"El Blog de Nessy"}},"markdownRemark":{"id":"980332af-7603-535a-8814-7a6f4727c1a0","excerpt":"Imagina que tienes que guardar un campo de RUT de pacientes en Firestore y que además tienes que preocuparte de no duplicarlos. ¿Cómo lo haces? Firestore no…","html":"

Imagina que tienes que guardar un campo de RUT de pacientes en Firestore y que además tienes que preocuparte de no duplicarlos. ¿Cómo lo haces?

\n

Firestore no tiene una forma nativa para guardar campos únicos, así que tenemos que usar técnicas para lograrlo.

\n

En este post, veremos una técnica para guardar campos únicos, que podría ser usada para no duplicar registros en base al RUT.

\n

Nota: El RUT es un número único implantado en Chile, que se usa como identificación tributaria. En registros clínicos, se suele usar para identificar al paciente de forma inequívoca.

\n

Meta

\n

La meta de este artículo es mostrarte un paso a paso de cómo lograr guardar valores únicos en un documento de firestore.

\n

Para el resto del artículo, consideraremos que existe una colección de pacientes (patients) y que queremos hacer que el campo rut sea único.

\n

¿Qué es un campo único?

\n

Un campo único es un dato particular que debe ser único entre todos tus registros.

\n

Estos van a depender de la aplicación que estés construyendo, pero algunos ejemplos que suelen ser únicos: identificadores, RUT de pacientes y correo electrónicos.

\n

¿Por qué guardar un campo único en Firestore no es fácil?

\n

Firestore no tiene la funcionalidad para guardar un campo único. No es como otros motores de base de datos donde puedes decir “mira, quiero que la propiedad rut sea única para todos estos registros”.

\n

Para lograrlo, hay que usar distintas técnicas, y va a depender de tu caso particular.

\n

¿Cómo podemos guardar un campo único?

\n

En este artículo veremos dos formas, las cuales van a depender de tu situación particular.

\n

La primera es la más sencilla: haz que el campo único sea el identificador de tu documento en Firestore. Te conviene esta solución cuando no puede existir un registro sin el dato.

\n

La segunda es más complicada: crea una colección para tu campo único y controla la escritura mediante reglas de seguridad. Te conviene esta solución cuando no puedes usar la primera.

\n

Alternativa #1: Haz que el campo único sea el identificador de tu documento en Firestore

\n

Si tienes registros de pacientes y por requerimientos siempre existirán pacientes con RUT, puedes optar por esta alternativa.

\n

Cuando crees pacientes, en vez de usar la función add():

\n
firestore().collection('patients').add(patientData);
\n

Tendrás que hacerlo con doc() y set():

\n
firestore().collection('patients').doc(patientData.rut).set(patientData);
\n

Luego te recomiendo agregar en Reglas de Seguridad que el ID del documento sea igual al RUT:

\n
match /patients/{patientId} {\n  allow create: if patientId == request.resource.data.rut;\n}
\n

Puedes validar también que patientId parezca un rut válido (mediante una expresión regular).

\n

Nota: para validar el dígito verificador, tendrías que hacerlo en una Cloud Function, ya que en Firestore Security Rules no puedes usar loops (aunque quizás es posible hacerlo sin loops 🙃).

\n

Alternativa #2: Crea una colección para tu campo único y controla la escritura mediante reglas de seguridad

\n

Si no puedes optar por la solución anterior, tendrás que hacer algo más complicado.

\n

La idea es tener una colección aparte, que sea como un mapa entre tu campo único y el ID del documento que lo tiene. Luego agregar validaciones mediante reglas de seguridad. A esta colección la llamaré identifiers.

\n

El resultado final será que para cada registro de paciente, también existirá un registro en la colección de identificadores. Por ejemplo:

\n

\n \n \n \n \n

\n

Paciente con ID = 5dedf…

\n

\n \n \n \n \n

\n

Identificador con ID = 1111111-1, y patientId = 5dedf…

\n

Para lograrlo, son dos pasos:

\n

1) Agregar colección de identificadores

\n

Al crear pacientes, ahora tenemos que también crear identificadores. Por ejemplo:

\n
const patientRef = firestore().collection('patients').doc() // ID auto generado\nconst identifierRef = firestore().collection('identifiers').doc(patientData.rut) // ID de RUT\n\nawait identifierRef.set({ patientId: patientRef.id })\nawait patientRef.set(patientData)
\n

Aquí estamos creando ambos documentos. El problema es que esta no es una operación atómica, es decir, si falla la creación de uno, el otro documento no se ve afectado.

\n

Para solucionar este problema, tenemos que usar escrituras en lotes (Batch writes):

\n
const batch = firestore().batch();\nconst patientRef = firestore().collection('patients').doc();\nconst identifierRef = firestore().collection('identifiers').doc(patientData.rut);\n\nbatch.set(patientRef, newPatient);\nbatch.set(identifierRef, { patientId: patientRef.id });\n\ntry {\n  await batch.commit();\n} catch {\n  // Ocurrió un error. Quizás el RUT ya estaba en uso :)\n}
\n

Con esto tenemos listo la primera parte. Ahora debemos hacer que esta operación falle si el RUT está en uso.

\n

2) Agregar reglas de seguridad para evitar duplicados

\n

Si ya existe un paciente con el RUT, la creación de paciente debe fallar. Como estamos usando una transacción, basta con la siguiente regla de seguridad:

\n
match /identifiers/{identifierId} {\n  allow create: if 'patientId' in request.resource.data;\n}
\n

Encapsulando la lógica anterior en una función llamada createPatient:

\n
async function createPatient(patientData) {\n\tconst batch = firestore().batch();\n\tconst patientRef = firestore().collection('patients').doc();\n\tconst identifierRef = firestore().collection('identifiers').doc(patientData.rut);\n\t\n\tbatch.set(patientRef, newPatient);\n\tbatch.set(identifierRef, { patientId: patientRef.id });\n\t\n\ttry {\n\t  await batch.commit();\n\t} catch {\n\t  // Ocurrió un error. Quizás el RUT ya estaba en uso :)\n\t}\n}
\n

Al intentar ejecutar el siguiente código, obtenemos el siguiente resultado:

\n
await createPatient({ rut: '11111111-1', name: 'Chewy 1' })\n// ^funciona, y crea al paciente y al identificador (id = 11111111-1)\nawait createPatient({ rut: '11111111-1', name: 'Chewy 2' })\n// ^falla, identificador id = 11111111-1 ya existe, la operación se considera\n// como un update, por lo tanto las reglas de seguridad la rechazan
\n

Esto ocurre porque el segundo llamado está escribiendo sobre el identifier con ID igual a 11111111-1, como ya existe, estamos hablando de una operación update la cual no es permitida.

\n

Pero la regla no evita que agreguemos los pacientes directamente:

\n
// Las siguientes llamadas funcionan:\nawait firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 1' });\nawait firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 2' });
\n

Ni tampoco evita que agreguemos identificadores cuando los pacientes no existen:

\n
await firestore().collection('identifiers').doc('11111111-1').set({ patientId: 'no existe' })
\n

Es por eso que necesitamos agregar las siguientes 2 reglas:

\n

1) Cuando creo un identificador, verificar que el paciente existe:

\n
function patientExists(identifierId) {\n  let identifier = getAfter(/databases/$(database)/documents/identifiers/$(identifierId)).data;\n  let patient = getAfter(/databases/$(database)/documents/patients/$(identifider.patientId)).data;\n  return identifierId == patient.rut;\n}\n\nmatch /identifiers/{identifierId} {\n  allow create: if patientExists(identifierId);\n}
\n

La función getAfter obtiene el documento asumiendo que la solicitud actual se realiza correctamente. Si el paciente no existe, la verificación fallará, ya que el getAfter del paciente fallaría.

\n

2) Cuando creo un paciente, verificar que el identificador existe:

\n
function identifierExists(patientId) {\n  let patient = getAfter(/databases/$(database)/documents/patients/$(patientId)).data;\n  let identifier = getAfter(/databases/$(database)/documents/identifiers/$(patient.rut)).data;\n  return identifier.patientId == patientId;\n}\n\nmatch /patients/{patientId} {\n  allow create: if identifierExists(patientId);\n}
\n

Esto es lo mismo que la regla anterior, pero desde el punto de vista del paciente.

\n

Gracias a estas dos reglas, los casos anteriores funcionan como deberían:

\n
// Prueba 1: ambas llamadas fallan porque no existe identifier\nawait firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 1' });\nawait firestore().collection('patients').add({ rut: '11111111-1', name: 'Chewy 2' });\n\n// Prueba 2: falla porque no existe paciente\nawait firestore().collection('identifiers').doc('11111111-1').set({ patientId: 'no existe' })
\n

La única forma de crear pacientes ahora es con una operación atómica, como la que tenemos en la función createPatient.

\n

Conclusión

\n

En este artículo vimos como implementar la funcionalidad de “campo único” en Firestore.

\n

Como ejemplo, nos pusimos en la situación donde queremos guardar pacientes con un campo único “RUT”, que es un identificador único que tienen los ciudadanos en Chile 🇨🇱. De todos modos, puedes usar las mismas técnicas para otros tipos de identificadores, tales como pasaporte, nombres de usuario o incluso correos.

\n

Las técnicas que vimos son 2:

\n
    \n
  1. La fácil, que es utilizando tu campo único como ID del documento.
    2. \n
  2. La difícil, que es utilizando una colección auxiliar que funciona como un registro que guarda los valores únicos.
    3. \n
\n

Me gustaría destacar que las técnicas mostradas le falta una capa adicional de privacidad, ya que el RUT estaría visible en el administrador:

\n

\n \n \n \n \n

\n

Además, ¿qué pasa si el campo único tiene caracteres que a Firebase no le gusta en sus IDs?

\n

Y solo vimos un único identificador, ¿cómo podemos hacer que existan otros tipos de identificadores? Por ejemplo, permitir que pacientes tengan RUT o Pasaporte.

\n

A continuación te dejo contenido extra de cómo abordar estos requerimientos.

\n

Extra: Cómo esconder el identificador

\n

Si no quieres que tu campo único esté visible desde Firebase:

\n

\n \n \n \n \n

\n

Puedes “ofuscar” el identificador, de manera que en vez de guardar el RUT, guardes su valor encriptado.

\n

Para esto, tienes que usar alguna función que esté disponible en Cloud Firestore Rules, por ejemplo, md5 o sha256.

\n

Usando sha256, el ID del documento ahora será el RUT encriptado:

\n
const patientId = sha256(patientData.rut)\nfirestore().collection('patients').doc(patientId).set(patientData)
\n

Y tendrías que actualizar las reglas de seguridad para verificar que el RUT del paciente sea igual al RUT encriptado:

\n
function verifyPatientId(patientId, patientData) {\n  return patientId == hashing.sha256(patientData.rut).toHexString().lower();\n}\n\nmatch /patients/{patientId} {\n  allow create: if verifyPatientId(patientId, request.resource.data);\n  allow update: if verifyPatientId(patientId, request.resource.data);\n}
\n

Así, el ID en vez de ser 11111111-1, queda en 5dedf71e6903bbb3c0b08ab5d94db62a4a5dea268bf2ef8d591089345989f82f

\n

\n \n \n \n \n

\n

El código de la segunda técnica bajo ofuscación te lo dejo como ejercicio 😆

","fields":{"tags":[{"name":"Tecnología","slug":"tecnologia"}]},"frontmatter":{"title":"Cómo implementar un campo único en Firestore","date":"08 de julio, 2022","description":"Imagina que tienes que guardar un campo de RUT de pacientes en Firestore y que además tienes que preocuparte de no duplicarlos. ¿Cómo lo haces?","author":{"slug":"nico","avatar":{"childImageSharp":{"fixed":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAEqUlEQVQ4y22T2XMUVRSH58kHtRDIOpnp7pnuniXbJJMdshEyIQnZYFgCRCKEJJCwC0mUFMpigEBYEtawhCAJBgEt1iqg1BIpKUuLguJBLV98sKzywb/h83SHzdKHU32r77nf/f3OPceRYMzCini9VL5lOP2VuFLqUNKiqBlLUcLNqFkr0SRUWSuhxbK3QHIacAaqSDBn22cnz8/C8RImG0nBGtySrGYuQ8teiTeniUC4iuRwBWaoEm84ije/E092i52jpC/ElVxLoq/8FfAlTDaU9EV4spaj5XUQyKkjMiOTmSGDUMCL36tieD2YGRGBtkuskdz3UEONorZeoJEXCstE2dznsGb0gnUYuUuIFGbRUJhCrplId1MthekBprz9DlPeegO3kYlR3PVc7cpJqKVUhDmsmrmlXprUR89fjV7cQ1p+PeVhnfLsIHvWr+Dvn+7y682z9K9vJqC5mD49BqNoI0ZJj5zpsJVa9pMC1ThcyXV28b25begzN2KW78aXs5gsbwxb3m3g6/Fh/vjhPs9ujzO27wM6Fs8hLjYWvbRHcnehF72PN281WmYT7tQGHJY66wbbqtzoqzyAUtTNqmiE7y4c4kTPOp5eO8mnOzbQ29JEX+ciQkGdpMIu/FUHMUo/FCEbbOuWSofVBp6cVvTCzZhlH+GbewSlbDe961r5/avLPL1+kd9ujPDZzg08GBng3qmdVBZlo5Rux1dzFHP2DrG/RRy2i9MlOGy7Itko3opPLHirBglFhzm9byd/PrrDXw9v8WB0kMObWngydoibxz5maSSbUN1B9JoTmJFPbGdeqaUWbhKg9JPVAkZJt2z2YcwdIjD/Agf6h3l8a4SHE2d4NHGRKwf3MLJ7CwPdzTRE2whGL2DUHMes2Dtpu2CtAJf/F2jWDKHXj5Kx9DIT54d5cuM0T66Mc3toP6N9a9nUuYLUxs8x549J7rH/Ab5m2Xpho/oI/nln0edfob1riHuXDvP07jVujwzS3VZLdbSF5MYv8TWcs93Yrl63bD2K97VHMSr346s/hdpwmc6uo5wb2Mq2zR00L6yhqthPbW09/uglzPqzGFUDrx4lr91uP7tttBdtU9qLOadfXvoQrpJe2lat4fGd0/Rva6dlUTndrdUsq5uJK7dF7A5K7gGMWdv/3TZ2Y0tT6nmtGAVtApcRTC1FDeYRidSI3XF+vHWeqyd3cfV4Lw3VFUyNV1ED+eKsEWOGDER+mz1p7tR51uhVoKXORgsWyIyGUMx0NH8WeuoMFH8eo4N7eXZ/gu+/OMPYUB/eQJgkPR3Vl4HLE8Stp0leLkqwREYvIkBDmtQUkC9TvhK+bNxmGE8wB5cklkdq+eWb6/z87R2qqqPEa2kCScepJZOgBCSC9jpR9RPrCuBIVFNw+7JEYQ5aIIckb7oNtEIVpdOcfjpXtbFkQSNvTnWR5EnB6Uklzu0nQRWQliKwZOLdAaYnaDhinSZOgShyWBGw6s+24YovbK9VuSTG5Ze6eXCJMivHLXsuI0OshwRowXwC8zAtXoAxiTpxcsACTKp6DhT7L1RbSj3B3EmY/LfCJfV2etJs27FJBlPj3EyLU/gHBhzbgqfkxlYAAAAASUVORK5CYII=","width":70,"height":70,"src":"/static/c454b7eddf2624b2e434eb2b68050446/31406/nico.png","srcSet":"/static/c454b7eddf2624b2e434eb2b68050446/31406/nico.png 1x,\n/static/c454b7eddf2624b2e434eb2b68050446/1edbf/nico.png 1.5x,\n/static/c454b7eddf2624b2e434eb2b68050446/b3779/nico.png 2x"}}},"bio":"Ingeniero Civil en Computación PUC.","github":"muZk","linkedin":"codewithnico","name":"Nicolás Gómez","twitter":"codewithnico"},"image":{"childImageSharp":{"resize":{"src":"/static/761134b417e50e230b0a57daed1def97/47498/preview.jpg","height":624,"width":1200}}}}},"previous":{"fields":{"slug":"/como-fue-trabajar-2-semanas-en-reino-unido/"},"frontmatter":{"title":"Cómo fue trabajar 2 semanas desde Reino Unido"}},"next":{"fields":{"slug":"/que-es-hl7-fhir/"},"frontmatter":{"title":"¿Qué es HL7 FHIR?"}}},"pageContext":{"id":"980332af-7603-535a-8814-7a6f4727c1a0","previousPostId":"e54242e8-b126-5735-a594-165f9ae03892","nextPostId":"078fce0a-8d37-503b-b55e-875f0130c3d9"}},"staticQueryHashes":["3832538981"]}