Le lun. 22 avr. 2019 à 20:39, John Cowan <xxxxxx@ccil.org> a écrit :

On Mon, Apr 22, 2019 at 1:30 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote:

As of right now the SRFI doesn't expose a predicates for the two disjoint types it expose. Should I add `store?` and `transaction?` predicates to the specification?

Yes.

I need to do this.

A more Schemey approach would be (in-transaction database proc failure success), which evaluates proc passing a newly created transaction as its argument.

 

When proc returns, the transaction is committed and in-transaction applies whatever proc returned to the success procedure and returns its result.

 

If proc calls "rollback" instead,

How does look the definition of that "rollback"? Isn't it a raise of some sort?

 

then the transaction is rolled back, the execution of proc is abandoned, failure is called with no arguments, and in-transaction returns its result.  By default failure is "raise" and success is "identity".

I will add `in-transaction` but as `transactional`, i prefer that naming, in SRFI 167 with the behavior you described and update `transactional` in SRFI 168 to be similar.

 

Right now, procedure "range" is specified to return a generator over the key-value pairs that starts with the parameter PREFIX. This is unlike what FDB does in fdb_transaction_get_range where the range is specified using "start" and "end" bytes. Also see the paragraph about KeySelector. Similarly python bindings of leveldb do specify start and end (ref). I think I will change "range" definition to look more like fdb_transaction_get_range. And add a "store-prefix" procedure that has the same definition as current "store-range" procedure.

Range is more powerful than prefix: for example, it can be used to capture the last 30 days of transactions using the range "20190323" to "20190422".  I'd go with it if I were you, even though it puts more demands on the store.

Yes indeed, thanks for helping me figure this out. I will update the document later.

 

 

As you can see in the pull-request, I replaced ARGS rest argument with a single CONFIG parameter that is an alist. I think I will also specify the expected keys in that alist along a few expected values, that may or may not be supported by implementations. But when applicable the the configuration must be the same across implementations. That is it will ease portability.

Makes sense. 

No done yet.

 

We already have, alas, "hashtables," which look to me like things that can be "hasht-ed."  

Well, R6RS does, but R7RS-large uses hash-table.

Changed to `okvs-roll-back` without exclamation mark.