It is John's Simple SQL API with "sql-" replaced with "sdbi-", and the following changes:
New opaque data type, tech-stack, and that's not a good name for the stack of e.g. "subprocess jdbc db2", suggestions including replacing "stack" are solicited.
Added before you create a connection, the initial alist specifies which database, how you connect to it, configuration, etc.:
(sdbi-stack-construct alist) -> tech-stack
(sdbi-stack-dismantle tech-stack) -> undefined
(sdbi-stack-adjust tech-stack alist) -> undefined
Options for -construct and -adjust include:
The next replaces the sql-timeout procedure, if we make timeouts a function of the stack, instead of a particular connection in it, which might be a virtual connection serviced by a connection pool.
(request-timeout . timespect-interval)
Set timeout in seconds and nanoseconds for each request on the
connection. Signal an error if request does not complete.
(connection-pooling . variety)
Where variety is #t to use the stack's default pooling, or a list of
procedures to supply a different pooling system.
(sdbi-tech-stack? obj) -> boolean
Minor change adding tech-stack to opening a connection, and the obvious -close procedure was added:
(sdbi-connection-open tech-stack alist) -> connection
The connection is virtual if connection pooling is enabled by
sdbi-stack-construct.
If you have connection pooling, would having a special case (specified in the alist) to provide a fixed connection be worthwhile?
As previously worked out on this list, sdbi-with-connection defaults to committing, so sql-commit has been removed.
Here I made thunk optional, removing needless ceremony and a procedure call if you just want the result set.
(sdbi-get-result connection statement [thunk]) -> result-set or what thunk returns
Executes statement, and thunk supplied, passes it the result-set.
Everything following, which starts with (sdbi-read result-set) -> list, is unchanged except for the"sql-" -> "sdbi-" swap.
- Harold