When writing transactions in application code you have 2 situations:

• A: You need to grab some data from the database, modify it in the app code, then do a subsequent SQL update using that modified app code data (second call depends upon first)
• B: You need to perform a series of commits that have no data dependencies on each other - either they must all succeed or all fail

Examples (little contrived) A:

1. start transaction trx
2. read from orders table the email addresses of everyone
3. in the app code (database client) send everyone an email
4. update every order to mark it's the user has been emailed
5. end transaction

B:

1. read from a csv text file containing orders (email, customer number) into memory
2. start transaction trx
3. in the app code, send everyone an email (assume none will fail)
4. insert into another table a historal log of who has been emailed as part of trx
5. update into a another table the total count of emails sent
6. end transaction trx

it's a little contrived but the point is, in case B, operations 4 and 5 don't need to be in the same transaction as 1. in such a case we want to build a knex query which would produce

BEGIN TRANSACTION INSERT INTO historicalEmailsSent ... SET count FROM emailsSentCount WHERE customer='custId' COMMIT

I'm not sure if knex does this today, when you create a transaction, e.g.

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

await trx('emailSentCount).update(...)
trx.commit();

my understanding is you will end up making 2 separate network requests to the database, holding the transaction open, when you could have made only one. This is because knex doesn't know if inbetween your first and second transaction, you do someething in your app code which then a later transaction depends upon.

Or am I mistaken?