| commit | c784cc4b21c554e276cb309b53f36fe8a2c5b8ac | [log] [tgz] |
|---|---|---|
| author | Nick Vatamaniuc <vatamane@gmail.com> | Mon Mar 29 18:47:53 2021 -0400 |
| committer | Nick Vatamaniuc <nickva@users.noreply.github.com> | Tue Mar 30 12:53:50 2021 -0400 |
| tree | 54763e15d8494aacd1edbb0fb176aa21f06bf1f3 | |
| parent | 53077693e161368f6c33b73a2f967fe490c36838 [diff] |
Make the default wait timeout infinity
This brings the default behavior in line with other FoundationDB client
libraries which don't use client-side timeouts when waiting for futures to
fire.
A few other reasons are:
* Currently we may generate spurious future `ready` messages when timeouts
fire during overload scenarios. The caller would have to know to flush ready
messages if they caught a `{timeout, _}`
* The response may succeed under 5 seconds, but it would be queued in the
networking layer and throw a `timeout` error on the Erlang side.
* Timeouts can be set as a transaction or db handle options. It's easier to
apply configuration defaults there than for individual wait functions.
* Watch futures are not bound by the 5 second transaction time limit, and
they'd have to know about the default `wait/1,2` call timeout to know to
extend it or set it to `infinity`.
This project is a NIF wrapper for the FoundationDB C API. Documentation on the main API can be found here.
This project also provides a conforming implementation of the Tuple and Directory layers.
Assuming you have installed the FoundationDB C API library, building erlfdb is as simple as:
$ make
Alternatively, adding erlfdb as a rebar dependency should Just Work ®.
Documentation for installing FoundationDB can be found here for macOS or here for Linux.
A simple example showing how to open a database and read and write keys:
Eshell V9.3.3.6 (abort with ^G) 1> Db = erlfdb:open(<<"/usr/local/etc/foundationdb/fdb.cluster">>). {erlfdb_database,#Ref<0.2859661758.3941466120.85406>} 2> ok = erlfdb:set(Db, <<"foo">>, <<"bar">>). ok 3> erlfdb:get(Db, <<"foo">>). <<"bar">> 4> erlfdb:get(Db, <<"bar">>). not_found
FoundationDB has a custom binding tester that can be used to test whether changes have broken compatibility. See the BINDING_TESTER documentation for instructions on building and running that system.