The engine procedures were supposed to abstract the underlying implementation to be able to swap implementation hence storage database backend at will in user code.
Another way I would call it, probably is: "predicate-based multi-methods" or "predicate-based multiple dispatch". See the following article:
In Python, it looks much like an abstractclass with the added support of multiple dispatch that is more powerful that single dispatch. See python documentation:
Also, the dispatch is done with any predicate that is slightly more powerful than Python's.
So, in okvslite, allprocedure will be generic methods.
The signature ofhas a problem: . That is symmetric with . We can simulate their use with the following code:
That is ok in most case, except the fact thatrest argument will force the creation of a new list in some (most?) scheme implementation, hence stress the garbage collector in the hot path. This is might not be a problem, if they were no easy faster alternatives. In that case, there is a performance trick that is also an enabler. We can change the signature of to:
Hence the above simulation becomes:
See thatdisappeared. That is not only slightly faster and memory efficient, and it will add the ability to pass any basic scheme object to as top level value. Possibly a instead of a list, and also an atomic value like some number, a boolean.
That will also enable another small optimization, again in the hot path, while reducing the complexity of the code in many cases. For instance, in the case where the value part is an atomic value, previously it was required to pass a list as value, otherwise said, the value was necessarily wrapped inside a list:
The new code is more readable:
Hence there is lessin the hot path .
In the SRFI document, I did not explain what is a transaction:
The full signature is:
The advantage of the Scheme approach is that it makes a stack shuffling aka. exception or non-local exit, optional, hence it makes some optimizations possible (compared to Pythonic code that rely on exceptions in similar cases). Most of the time with Scheme exceptions are opt-in. Also the code is much shorter, and suggest to create a procedure withand which leads to more readable code.
More on: I think I will drop all-around from all procedures because this is really here to enable some optimizations with wiredtiger, but wiredtiger... is useful but rather obscure, I need to document more cases that makes use of it (mind the fact that is the last optional argument when config will be gone).
A big change that is coming is to merge query Domain Specific Language. So, looks like:and to make it explicit that the API is the
A common realization is to query:
To retrieve a reversed generator, that is fromto where is excluded:
Thenwill have a similar signature.
I thinkmust be called again in the case where rollback to replay the transaction.
Prolly, similarly to, hooks are too advanced, and I do not use them anymore...