-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EP - Muestra el numero total de fichas filtradas por el buscador #1668
Conversation
Object.keys(options).map(opt => delete conditions[opt]); | ||
const [results, total] = await Promise.all([ | ||
SeguimientoPacienteCtr.search(conditions, options), | ||
SeguimientoPacienteCtr.search(conditions) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recomiendo utilizar el metodo count de mongo, porque puede llegar a ser muchos resultados.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
El inconveniente acá es el filtro por fecha que ya está armado para el recurso. Habría que volverlo a descomponer en dos fechas para poder ejecutarla como query de mongo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@negro89 Si no entiendo mal el problema con esta solución, es que no solo se anula la ventaja de performance de usar skip & limit, sino que además le agregamos el trabajo de la busqueda total por cada busqueda segmentada (search con skip & limit + search sin opciones de paginación), cuando la motivación de segmentar la query es justamente alivianar y mejorar los tiempos de búsqueda. Una alternativa podría ser dejar la búsqueda de fichas como está actualmente, y por otro lado agregar un nuevo endpoint GET que devuelva la cantidad total de fichas que responden al criterio de búsqueda dado, utilizando, como sugería Mariano, el método count, así se evita traerse todos los registros a la api para contarlos ahi. Adicionalmente, del lado de la app se podría buscar la manera de "cachear" (asi entre comillas jaja), el nro total de registros para un filtro determinado, de manera que no haya necesidad de contar el total registros cada vez que el scroll infinito hace la busqueda de la siguiente paginación (solo volver a calcular el total si se cambia el valor de los filtros).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Se hizo una pequeña correccion para corregir la consulta por el total cada vez que se ejecuta ese endpoint.
Se reemplaza por funcionalidad mas general directamente desde el resourse base andes/api-tools#52 |
Requerimiento
https://proyectos.andes.gob.ar/browse/EP-184
Funcionalidad desarrollada
UserStories llegó a completarse
Requiere actualizaciones en la base de datos