From: Amirouche Boubekki <xxxxxx@gmail.com>
Date: Saturday, June 29, 2019 6:26 AM
[...]
Does okvs-debug do its thing in an implicit transaction like the okvs-prefix explicitly does when called with an empty bytevector prefix?
I don't understand, can you show me some code?
You answered this in a reply to Rhys Ulerich, okvs-debug does all its operations inside one transaction.
If you view it as a general vs. debug function, as the suggested name change suggests, adding range arguments or adding an additional function "-range" would make it more efficient for more uses. I'm assuming that because operating on a range of keys is required in other functions, adding this wouldn't be onerous.
This would be onerous in the sense that it will add more "moving pieces" to the specification. Of course, in real world scenario production database you would not use okvs-debug. And instead rely on okvs-prefix or okvs-range. But that would only small helpers on top of OKVS that doesn't change the spirit of the specification. One way to make easier to debug live databases would be to come up with a generator syntax that reduce the "boilerplate" code related to chaining generators:
(okvs-in-transaction db (lambda (txn) (generator-for-each (lambda (key value) (unpack key) (unpack value)) (okvs-prefix txn (pack 'my 'subspace)))))
I can see people preferring to map over a subset of keys vs. using the generator approach,
It rely on generator because that is what is the most performant over map / filter et al.
Roughly how much more performant is using a generator is over map / filter et. al.?
However, one "right" way of doing this has great appeal and Scheme style, and as you note fewer moving pieces. I like John Cowan's suggestion of dropping okvs-debug altogether; why not include in an example section code that will operate over all keys in the database, displaying each key and value?
that's not the only way people will use it, especially if they're manipulating OKVSes with schema defined by other non-Scheme applications.
How is that related? If people share the same database with another language only the (lexicographic) packing procedure is interesting.
The packing / unpacking procedure was removed from the specification because of that very reason:
Do we want compatibility with existing packing algorithm or more Scheme objects support?
Not necessarily either; for people using a database defined by another non-Scheme application, it should be up to them to make sense of the raw bytevectors.
[ As discussed, the R7RS hash table issues need to be nailed down. ]
The [failure [success]] options in okvs-in-transaction look like they would be *really* useful in the begin and rollback or commit transaction approach. Perhaps only add them to okvs-transaction-begin to avoid Don't Repeat Yourself (DRY)?
I don't understand why it would be useful to add to transaction-begin.
To provide callback style error handing when either transaction-commit or transaction-rollback are called, if the same behavior is desired for both. I'm not sure if there are any good use cases for this besides logging. Adding [failure [success]] to okvs-commit and okvs-rollback would have a much higher payoff.
[...]
- Harold