verdnatura/hedera-web
verdnatura
/
hedera-web
0
1
Fork 3
Code Issues Pull Requests 3 Releases Wiki Activity

fix: migrate pending orders #121

Merged
jsegarra merged 7 commits from ldragan/hedera-web:taro/pending-orders into beta 2025-03-27 05:15:04 +00:00
Conversation 1 Commits 7 Files Changed 3 +6 -7
2 changed files with 6 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 512b0b5e9c - Show all commits

2
src/pages/Ecomerce/PendingOrders.vue
View File

@ -32,7 +32,7 @@ const getOrders = async (clientFk) => {
const filter = {
where: {
clientFk,
isConfirmed: 0,
isConfirmed: false,
jsegarra commented 2025-03-25 08:28:51 +00:00
Outdated
Review
Copy Link

a nivel de BD funciona bien, pero como lo consultamos desde el front, mejor aplicamos del standard Booleano true/false

a nivel de BD funciona bien, pero como lo consultamos desde el front, mejor aplicamos del standard Booleano true/false
source_app: 'WEB',
},
include: [
jsegarra marked this conversation as resolved
jsegarra commented 2025-03-12 22:34:21 +00:00
Review
Copy Link

haces para que te traiga el objeto de address?
Quiero decir, la relacion ya está con clave primaria, por tanto no haria falta ponerlo en el where

haces para que te traiga el objeto de address? Quiero decir, la relacion ya está con clave primaria, por tanto no haria falta ponerlo en el where
ldragan commented 2025-03-13 04:49:34 +00:00
Review
Copy Link

Coincido, pero así estaba la query y preferí no cambiarla. (La view myAddress tiene incluido el filtro de clientFk).

Por lo que veo en order.json, el join se hace via el address_id, y no hay una garantía real y determinística de que el address.clientFk coincida con el order.clientFk— ello depende de que nunca se haga un insert o update "incorrecto" en algún lugar del código, para alguna defición de "correcto".

Yo considero que remover esta parte del where sería un refactor, y no es estrictamente parte de la migración. Estoy a favor, pero suelo preferir el camino conservador, y encarar los dos cambios en 2 PRs separados, para simplificar el debugging en el remoto caso de que ocurra un error inesperado por alguna incongruencia en la data.

Por otro lado, lo más probable es que remover esta condición no cause ningún problema, y, aún si lo hiciera, el impacto debería ser mínimo, inmediatamente observable y fácil de resolver.

Si estás a favor de quitar el 'address.clientFk': clientFk,, entonces yo también :)

Coincido, pero así estaba la query y preferí no cambiarla. (La view `myAddress` tiene incluido el filtro de `clientFk`). Por lo que veo en `order.json`, el `join` se hace via el `address_id`, y no hay una garantía real y determinística de que el `address.clientFk` coincida con el `order.clientFk`— ello depende de que nunca se haga un `insert` o `update` "incorrecto" en algún lugar del código, para alguna defición de "correcto". Yo considero que remover esta parte del `where` sería un refactor, y no es estrictamente parte de la migración. Estoy a favor, pero suelo preferir el camino conservador, y encarar los dos cambios en 2 PRs separados, para simplificar el debugging en el remoto caso de que ocurra un error inesperado por alguna incongruencia en la data. Por otro lado, lo más probable es que remover esta condición no cause ningún problema, y, aún si lo hiciera, el impacto debería ser mínimo, inmediatamente observable y fácil de resolver. Si estás a favor de quitar el `'address.clientFk': clientFk,`, entonces yo también :)
jsegarra commented 2025-03-21 14:26:39 +00:00
Review
Copy Link

Dale con todo y quitemosla

Dale con todo y quitemosla
jsegarra commented 2025-03-21 14:29:52 +00:00
Review
Copy Link

y validamos con los tests

y validamos con los tests
ldragan commented 2025-03-22 15:10:08 +00:00
Review
Copy Link

Awesome. Hecho :)

Awesome. Hecho :)

11
src/utils/onUserId.js
View File

@ -7,12 +7,11 @@ const userStore = useUserStore();
export const onUserId = (cb) => watch(
() => userStore?.user?.id,
async userId => {
if (userId) {
try {
await cb(userId);
} catch (error) {
console.error(error);
}
if (!userId) return;
jsegarra commented 2025-03-25 08:24:15 +00:00
Outdated
Review
Copy Link

Usando clausulas de guarda podemos quitar un nivel de indexación
if (!userId) return;

Usando clausulas de guarda podemos quitar un nivel de indexación ` if (!userId) return;`
❤️ 2
try {
await cb(userId);
} catch (error) {
console.error(error);
}
},
{ immediate: true }