I'm not sure exactly what a rollback call ought to do though after
aborting the transaction; should it invoke the continuation of the
closest with-transaction block?
I've been thinking that is the Right Thing, though my pre-pre- doesn't say so. Any objections to that idea? Given that SQL calls are basically imperative, it makes sense not to attempt any more of them after an abort.
Then perhaps the rollback procedure
should also accept the value(s) to pass to said continuation as rest
args: (rollback! db return-value1 ...)
+1
Just continuing with the regular flow seems unwise to me, as those
statements would then be taking place in the parent transaction.
Or would be auto-committed, if there is no parent (as would typically be the case), which is the Worst Possible Thing.
By the way (this belongs somewhere else, but I'm too lazy to look for it right now), <
https://www.connectionstrings.com/> makes it clear that connection strings are de facto standardized and that they are a flattening of a string-to-string alist, which is how we should represent them in Scheme. Not a p-list, because the keys frequently have spaces, and "..." is easier and more portable than |...|. So I have made an alist the only argument of open-sql-connection.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgThere are books that are at once excellent and boring. Those that at
once leap to the mind are Thoreau's Walden, Emerson's Essays, George
Eliot's Adam Bede, and Landor's Dialogues. --Somerset Maugham