Al escribir transacciones en el código de la aplicación, tiene 2 situaciones:

• R: Debe obtener algunos datos de la base de datos, modificarlos en el código de la aplicación y luego realizar una actualización de SQL posterior utilizando los datos del código de la aplicación modificados (la segunda llamada depende de la primera)
• B: debe realizar una serie de confirmaciones que no tengan dependencias de datos entre sí, ya sea que todas tengan éxito o todas fallen

Ejemplos (poco inventados) A:

1. iniciar transacción trx
2. leer de la tabla de pedidos las direcciones de correo electrónico de todos
3. en el código de la aplicación (cliente de la base de datos) envíe un correo electrónico a todos
4. actualice cada pedido para marcar que el usuario ha sido enviado por correo electrónico
5. finalizar transacción

B:

1. leer desde un archivo de texto csv que contiene pedidos (correo electrónico, número de cliente) en la memoria
2. iniciar transacción trx
3. en el código de la aplicación, envíe a todos un correo electrónico (suponga que ninguno fallará)
4. inserte en otra tabla un registro histórico de quién ha sido enviado por correo electrónico como parte de trx
5. actualizar en otra tabla el recuento total de correos electrónicos enviados
6. finalizar transacción trx

es un poco artificial, pero el punto es que, en el caso B, las operaciones 4 y 5 no necesitan estar en la misma transacción que la 1. En tal caso, queremos crear una consulta knex que produzca

COMENZAR TRANSACCIÓN INSERTAR EN correos electrónicos enviados históricamente... CONFIGURAR el recuento DESDE correos electrónicos enviados Cuenta DONDE cliente = 'id del cliente' COMMIT

No estoy seguro si knex hace esto hoy, cuando crea una transacción, por ejemplo

 const trx = knex.trasnaction(); await trx('historicalEmailsSent).udpdate(...) await trx('emailSentCount).update(...) trx.commit();

Tengo entendido que terminará haciendo 2 solicitudes de red separadas a la base de datos, manteniendo abierta la transacción, cuando podría haber hecho solo una. Esto se debe a que knex no sabe si entre su primera y segunda transacción, usted hace algo en el código de su aplicación de lo que depende una transacción posterior.

¿O me equivoco?