From: Amirouche Boubekki <xxxxxx@gmail.com>

Date: Tuesday, July 02, 2019 8:40 AM

Le mar. 2 juil. 2019 à 15:16, <xxxxxx@ancell-ent.com> a écrit :

OK; especially since it's my idea, I volunteer to create the API, and code an implementation.

You are welcome.

My last ideas:

- validating individual key operation as they happen in okvs-set! maybe okvs-delete!

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

- validating whole transactions

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.

Also, it should not make impossible the use of multiple abstraction in the same okvs. 

Isn't that implemented by convention through prefixes?

- Harold