Definitely both, and potentially beyond validating, to for example implement cascading deletes if the schema demands that.

I haven't yet figured out anything we can do beside follow the SQL RDBMS model.

Note this is implemented by full fledged stored procedures, they'll need to be handed the transaction handle because they can and may need to do arbitrary database operations.  This has implementation implications for the 'no-transaction concept, it could turn what appears to be a single operation into multiple ones that all need to be wrapped in the same transaction.

A bit of searching revealed that Wiretiger doesn't seem to have nested transactions, but Oracle's Sleepycat Berkeley DB does, so the concept is not alien to KVSes.  Do we want to make any provisions for them?  In terms of the API prior to the 'no-transaction update, it could be very simple by handing okvs-transaction-begin and okvs-in-transaction the existing outer transaction handle instead of the okvs database handle.  If not, the SRFI should state it's an error to begin a transaction inside another.

Isn't that implemented by convention through prefixes?

- Harold