You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To implement nested transactions, drizzle creates savepoints - here.
It appear that the savepoints queries are executed with the savepoint name as parameter which is not supported by AWS Data API (or at least seems to be, I haven't found the confirmation).
// succeeds
aws rds-data execute-statement --resource-arn $RESOURCE --secret-arn $SECRET --database $DB --sql "BEGIN; INSERT INTO test VALUES ('a'); SAVEPOINT sp1; INSERT INTO test VALUES ('b'); ROLLBACK TO SAVEPOINT sp1; INSERT INTO test VALUES ('c');COMMIT;"
// fails
aws rds-data execute-statement --resource-arn $RESOURCE --secret-arn $SECRET --database $DB --sql "BEGIN; INSERT INTO test VALUES ('a'); SAVEPOINT :1; INSERT INTO test VALUES ('b'); ROLLBACK TO SAVEPOINT :1; INSERT INTO test VALUES ('c');COMMIT;" --parameters '[{"name":"1","value":{"stringValue":"sp1"}}]'
I noticed that the creation & release/rollback of the savepoints are not awaited - here. It produce a strange behavior were we entre inside the nested transaction block even if the transaction creation failed.
In the example above it means that the 3 logs are executed & 2 unhandled promise rejections are created (queries savepoint sp1; & release savepoint sp1;).
Is it intentional?
What version of
drizzle-orm
are you using?0.29.3
What version of
drizzle-kit
are you using?No response
Describe the Bug
To implement nested transactions, drizzle creates savepoints - here.
It appear that the savepoints queries are executed with the savepoint name as parameter which is not supported by AWS Data API (or at least seems to be, I haven't found the confirmation).
You can easily repro via:
savepoints open/close
I noticed that the creation & release/rollback of the savepoints are not awaited - here. It produce a strange behavior were we entre inside the nested transaction block even if the transaction creation failed.
In the example above it means that the 3 logs are executed & 2 unhandled promise rejections are created (queries
savepoint sp1;
&release savepoint sp1;
).Is it intentional?
Expected behavior
The following code succeeds:
Environment & setup
No response
The text was updated successfully, but these errors were encountered: