feat: add missing dataloaders and optimize some #311
Conversation
| }), | ||
| }, | ||
| resolve: async (root, { input }, { DB, USER }) => { | ||
| const wheres: SQL[] = []; |
There was a problem hiding this comment.
Estos wheres no se utilizaban
src/schema/events/types.ts
Outdated
| SelectTicketSchema[] | undefined | ||
| >(); | ||
|
|
||
| const ticketsPromises = ids.map(async (eventId) => { |
There was a problem hiding this comment.
lo ideal sería una sola query a la BD pero dado que se está abstrayendo lógica con searchTickets lo dejo así
| purchaseOrder, | ||
| ticketsIds, | ||
| }; | ||
| return purchaseOrder; |
There was a problem hiding this comment.
No se usan realmente los ticketsIds en el resolver.
Por eso cambié el PurchaseOrderRef y por eso cambie el tipo de retorno aquí.
| values: purchaseOrderStatusEnum, | ||
| }); | ||
|
|
||
| export const PurchaseOrderRef = builder.objectRef<{ |
There was a problem hiding this comment.
Creo que no era necesario tipar esto como:
{
ticketsIds: string[];
purchaseOrder: typeof selectPurchaseOrdersSchema._type;
}| export const PurchaseOrderLoadable = builder.loadableObject(PurchaseOrderRef, { | ||
| description: "Representation of a Purchase Order", | ||
| load: async (ids: string[], context) => { | ||
| const result = await context.DB.query.purchaseOrdersSchema |
There was a problem hiding this comment.
Creo que no es necesario traer los userTickets, nos podemos ahorrar esa query.
No encuentro como se usan los userTickets después ni cual es el beneficio de hacer la query de ello aquí.
|
@TextC0de dañe este PR con el dataloader de cupons, Cómo quieres proceder? Soluciono el conflicto? o tienes suficiente contexto? Sorry :( |
|
Solucionado el merge conflict @joseglego |
| required: false, | ||
| }), | ||
| }, | ||
| resolve: async (root, { input }, { DB, USER }) => { |
There was a problem hiding this comment.
Por qué pasar de resolve a load?
There was a problem hiding this comment.
En la linea 345, se pasó de t.field a t.loadableList.
Este cambio fue necesario para implementar el método load, que aprovecha el patrón de DataLoader, agrupando múltiples solicitudes en una sola operación a la DB para optimizar el rendimiento.
Ahora, resolve se encarga de devolver los IDs de los eventos, que posteriormente se procesan en load (usando eventIds).
Este patrón es ideal cuando se devuelven múltiples eventos a una consulta, ya que evita el problema de N+1 reduciendo la cantidad de operaciones individuales ejecutadas en la DB.
Ejemplo de uso típico de la query:
query Events(
$input: PaginatedInputEventsSearchInput!
$ticketsInput: EventsTicketTemplateSearchInput!
) {
searchEvents(input: $input) { # Generalmente input.search.id es un solo ID
data {
id
tickets(input: $ticketsInput) { // los tickets relacionados a cada evento
id
}
}
}
}Lo que haría el nuevo código:
- Se ejecuta una consulta inicial para obtener los eventos (searchEvents).
loadableListrecibe todos los IDs de eventos.- Por cada evento, se ejecuta en paralelo (Promise.all):
- Verificación de permisos.
- Búsqueda de cupones si es necesario.
- Obtención de tickets.
Evitar el N+1 en este resolver implicaría más cambios en la lógica y no un simple Promise.all.
Lo ideal sería 1 sola query a la BD que permita traer todos los tickets relacionados a los eventsIds en cuestión pero no quise meterme ahí aún.
El cambio actual apunta a preparar el camino para una futura revisión de esta query, mantiene el PR pequeño y permite centrarse también en los otros DataLoaders que se incluyen en el PR.
Más info:
No description provided.