> On Apr 9, 2020, at 9:29 PM, Howard Chu <[email protected]> wrote: > > > A language binding should be a transparent pipe. It should relay whatever > parameters the caller supplied > down to the underlying library, and return the results. It shouldn't try to > guess at or impose any behaviors.
So, this is the current interface (that, again, I inherited): https://www.rubydoc.info/gems/lmdb/LMDB/Environment#transaction-instance_method I won’t bore you with the details, in part because I already have, but there is a considerable amount of (once again, inherited) bookkeeping under the hood to make that syntax work. The problem is it only works under extremely favourable conditions and it is my intention to rip much of that bookkeeping out. The purpose of this thread is to try to narrow down somewhat on what to replace it with. Again, if I could have gleaned this information successfully from the documentation, I never would have bothered you. If you’re amenable to a patch to said documentation, I am more than willing to provide one that would have answered my questions before asking them. The information you have given me so far in this thread is valuable and could readily be integrated into the documentation. > In this particular case, transaction nesting is already documented to only be > supported for write txns, > and an error will be returned for any attempt to use nesting with a read txn. > The binding should allow > the caller to try anything, and return the underlying error code when it > fails. Here’s a question then: is the error returned from a) attempting to nest a read-write transaction under a read-only transaction, or b) attempting to nest a read-only transaction at all, distinct enough from other errors to act properly on? (Where “act properly” means “trap the error and either raise an exception in the higher-level language or ignore it and do a no-op, or whatever”.) Thanks, -- Dorian Taylor Make things. Make sense. https://doriantaylor.com
signature.asc
Description: Message signed with OpenPGP
