Conversation
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| (t) => ({ | ||
| eventIdIndex: index("coupons_event_id_index").on(t.eventId), | ||
| codeIndex: index("coupons_code_index").on(t.code), | ||
| uniqueEventCodeIndex: uniqueIndex("coupons_event_code_unique_index").on( |
| if (couponId && couponId.length > 0) { | ||
| wheres.push(eq(ticketsSchema.couponId, couponId)); | ||
| } else { | ||
| wheres.push(isNull(ticketsSchema.couponId)); |
There was a problem hiding this comment.
Creo que esto haría que todos los tickets sin cupon no se muestren o no?
There was a problem hiding this comment.
Sip! La idea es que si no tienes un coupon válido. SOLO devuelve tickets publicos (sin coupon)
| eventIdIndex: index("coupons_event_id_index").on(t.eventId), | ||
| codeIndex: index("coupons_code_index").on(t.code), | ||
| uniqueEventCodeIndex: uniqueIndex("coupons_event_code_unique_index").on( | ||
| t.eventId, |
There was a problem hiding this comment.
Creo que el código no deberia ser unico por evento, sino que por ticket.
Por ejemplo, para 9punto5 teniamos dos entradas:
- Experiencia
- Conferencia
Y en ambos tickets se debía poder usar un mismo código
There was a problem hiding this comment.
Sip, esta implementación te permite esto. Al crear el código A para 9punto5, puedes tener 2 tickets, cada ticket debe tener este código A.id como couponId. y listo.
Es tal cuál como comentas. tenemos many tickets y one event en la definición de relations
There was a problem hiding this comment.
Ok, entiendo, tienes razon que lo permite 👍
| .notNull(), | ||
| stripeProductId: text("stripe_product_id"), | ||
| mercadoPagoProductId: text("mercado_pago_product_id"), | ||
| couponId: uuid("coupon_id").references(() => couponsSchema.id), |
There was a problem hiding this comment.
Un mismo ticket debería poder tener varios cupones de descuento asociados.
Cada uno de estos cupones podría aplicar distintos montos de descuento.
There was a problem hiding this comment.
Igual entiendo que esto es para un MVP similar a lo de 9punto5 pero mejor jajja.
Entonces me imagino van a crear un ticket por cada cupón?
No se como lo iban a implementar pero si es para el MVP tan solo un campo "mvpCoupon" de text podría servir creo por ahora???
There was a problem hiding this comment.
En general, respondiendo tu comentario y comentario de comentario 😆
Sip, es la reimplementación de los de 9punto5, (digamos que 9punto5 es v1, esto es V1.1) creo que nos queda mucho por iterar. La idea de reusar eso es para que así la lógica del purchaseOrder continuará sin ningún cambio. Me pareció lo más sencillo por limitaciones de tiempo y que era el approach más económico.
Sip, yo creería que más que mvp es v1.1. No agregué el prefix para que no lleguemos a versión final_final_este_si_de_verdad 🤣
| if (couponId && couponId.length > 0) { | ||
| wheres.push(eq(ticketsSchema.couponId, couponId)); | ||
| } else { | ||
| wheres.push(isNull(ticketsSchema.couponId)); |
There was a problem hiding this comment.
Creo que esto haría que todos los tickets sin cupon no se muestren o no?
3 participants
Summary