New traits with the same name as the old have been introduced which have almost an identical API surface, but the traits are not async.
AsyncStorage and AsyncDatabase are new wrapper types that are able to be used in async code. While the same types under the hood are used, these wrappers provides an "async-safe" API surface where users can trust every available function is safe to be called in an async context.
Motivation
Under the hood, BonsaiDb has always wrapped Nebari by calling tokio::task::spawn_blocking. Under the hood, tokio manages a threadpool for these blocking operations. A few days ago, I had the thought experiment of seeing what it would take to offer a non-async interface. After some investigation, I found there were only two locations in bonsaidb-local that leveraged async in any beneficial way, and those two locations were easy to update with alternate options.
After confirming I theoretically could do this, I decided to see what the effects would be. There is still a lot of work left in this PR, but I'm excited at the prospects of these changes.
Tasks to complete
[x] Implement sync traits in Client
[x] Fix all doc examples in sync traits
[x] Allow apis to bubble up database errors.
[x] Create new type for assuming identities (allow either a username or an id)
[x] Namespace custom apis
[x] Figure out permission handling for apis. The API should be able to be granted independent permissions from the user that's making the request. While this question was raised in this pull request, it might be better to sort out as a separate issue.
[x] Switch PubSub to use Serialize for Topic rather than Strings.
[ ] Decide what to do with examples (Convert all local to non-async?)
[ ] Update user guide to primarily be non-async, with a section describing the changes to adopt async
This pull request renames these existing traits:
ConnectionbecomesAsyncConnectionStorageConnectionbecomesAsyncStorageConnectionPubSubbecomesAsyncPubSubSubscriberbecomesAsyncSubscriberKeyValuebecomesAsyncKeyValueNew traits with the same name as the old have been introduced which have almost an identical API surface, but the traits are not async.
AsyncStorageandAsyncDatabaseare new wrapper types that are able to be used in async code. While the same types under the hood are used, these wrappers provides an "async-safe" API surface where users can trust every available function is safe to be called in an async context.Motivation
Under the hood, BonsaiDb has always wrapped Nebari by calling
tokio::task::spawn_blocking. Under the hood, tokio manages a threadpool for these blocking operations. A few days ago, I had the thought experiment of seeing what it would take to offer a non-async interface. After some investigation, I found there were only two locations in bonsaidb-local that leveraged async in any beneficial way, and those two locations were easy to update with alternate options.After confirming I theoretically could do this, I decided to see what the effects would be. There is still a lot of work left in this PR, but I'm excited at the prospects of these changes.
Tasks to complete