Cuando se crea una aplicación, a menudo se produce una situación en la que los usuarios desean eliminar algún contenido, pero es necesario saber que los datos existieron en su día.
Supongamos que estás creando una aplicación de mensajería. Puede que quieras dar a tus usuarios la posibilidad de restaurar conversaciones borradas.
Así que, cuando alguien viene a borrar una conversación necesitas hacer algo más que simplemente borrar el documento de Couchbase. En su lugar, podrías utilizar una bandera en el cuerpo JSON que identifique el documento como no vivo de alguna manera. Por ejemplo:
|
1 2 3 |
{ "borrado": verdadero } |
Debajo crearías un índice GSI para acceder de forma eficiente a todos esos suprimido conversaciones:
|
1 |
CREAR ÍNDICE deletedmsgs EN `conversaciones`(suprimido); |
A continuación, para rellenar la vista de conversaciones eliminadas en la interfaz de usuario de la aplicación, se ejecutaría un comando Consulta N1QL como:
|
1 |
SELECCIONAR * DESDE `conversaciones` DONDE suprimido = verdadero; |
Hasta ahora, todo parece bastante obvio.
Añadir esto a un conjunto de datos existente
Ahora bien, ¿qué ocurre si acabas de introducir esta función en tu aplicación? Lo más probable es que ya tengas muchos miles de conversaciones cuyos documentos subyacentes no tengan la función suprimido bandera.
Puede que esto le parezca una gran oportunidad para utilizar la función de N1QL FALTA. Tendrías razón, pero puede que estés pensando en algo distinto a lo que voy a sugerir.
Usted coulc cuenta los documentos que no tienen el suprimido cambiando su consulta N1QL a algo como esto:
|
1 |
SELECCIONAR * DESDE `conversaciones` DONDE suprimido = verdadero O suprimido IS FALTA; |
Para hacerlo un poco más realista, también podríamos filtrar nuestra consulta en función de la persona implicada:
|
1 |
SELECCIONAR * DESDE `conversaciones` DONDE remitente = usuario123 Y suprimido = verdadero O suprimido IS FALTA; |
Esto haría el trabajo, pero no sería la forma más eficiente de hacerlo.
Una vez que introducimos la palabra clave MISSING de N1QL en una situación OR, entonces lanzamos a N1QL a un escaneo completo del documento: nuestra consulta le está pidiendo a N1QL que revise cada documento en busca de la presencia de la clave JSON eliminada. Nuestro índice sólo ayuda con aquellos documentos en los que suprimido porque no indexa documentos en los que la clave no está presente.
En su lugar, en este caso, sería mejor ejecutar una única consulta que devolviera todos los documentos que faltan suprimido. A continuación, podríamos trabajar en cada uno de ellos y actualizarlos para incluir borrado = false y así todos esos documentos estarían ahora en nuestro índice eficiente.
Si la consulta tarda un poco más, no pasa nada: la ejecutaríamos como parte de una tarea de limpieza de datos en segundo plano, por lo que ninguno de nuestros usuarios se daría cuenta. Una vez que hayamos ejecutado esta tarea en todos los documentos, ya no necesitaremos FALTA en nuestra consulta de cara al usuario porque sabríamos que todos nuestros documentos de conversación serían borrado: true o borrado: falso.
Utilización de versiones de esquemas
Podríamos evitar por completo el uso de MISSING manteniendo el versionado del esquema:
|
1 2 3 |
{ "esquema": "1.2.3" } |
Si imaginamos que nuestra nueva versión del esquema, con el suprimido era 2.0.0, nuestra tarea de limpieza en segundo plano podría buscar todos los documentos que tuvieran una versión del esquema anterior a 2.0.0 y someterlos a un proceso de actualización, parte del cual consistiría en añadir el parámetro suprimido bandera.
