diff --git a/hotshot_query_service/all.html b/hotshot_query_service/all.html
index 87f6ae181..555416e8b 100644
--- a/hotshot_query_service/all.html
+++ b/hotshot_query_service/all.html
@@ -1 +1 @@
-List of all items in this crate
\ No newline at end of file
diff --git a/hotshot_query_service/availability/enum.BlockId.html b/hotshot_query_service/availability/enum.BlockId.html
index 6d5caab76..7b516af9f 100644
--- a/hotshot_query_service/availability/enum.BlockId.html
+++ b/hotshot_query_service/availability/enum.BlockId.html
@@ -1,8 +1,9 @@
-BlockId in hotshot_query_service::availability - Rust
Instruments this type with the provided Span, returning an
diff --git a/hotshot_query_service/availability/enum.Error.html b/hotshot_query_service/availability/enum.Error.html
index 777f898c4..1a7767dd1 100644
--- a/hotshot_query_service/availability/enum.Error.html
+++ b/hotshot_query_service/availability/enum.Error.html
@@ -1,4 +1,4 @@
-Error in hotshot_query_service::availability - Rust
Returns an iterator for traversing the chain of errors,
starting with the current error
-and continuing with recursive calls to Error::source. Read more
For maximum effectiveness, this needs to be called as a method
diff --git a/hotshot_query_service/availability/enum.Fetch.html b/hotshot_query_service/availability/enum.Fetch.html
index ed8835522..36a47599e 100644
--- a/hotshot_query_service/availability/enum.Fetch.html
+++ b/hotshot_query_service/availability/enum.Fetch.html
@@ -1,4 +1,4 @@
-Fetch in hotshot_query_service::availability - Rust
Convert this Fetch to a Result with the provided error context.
The result indicates whether the requested data is immediately available. If it is, Ok
is returned. Otherwise, an error is created from context using Snafu.
The availability API provides an objective view of the HotShot blockchain. It provides access
only to normative data: that is, data which is agreed upon by all honest consensus nodes and
which is immutable. This means access to core consensus data structures including leaves,
diff --git a/hotshot_query_service/availability/struct.CustomSnafu.html b/hotshot_query_service/availability/struct.CustomSnafu.html
index 5d7d10f09..e00e6e2d8 100644
--- a/hotshot_query_service/availability/struct.CustomSnafu.html
+++ b/hotshot_query_service/availability/struct.CustomSnafu.html
@@ -1,17 +1,17 @@
-
CustomSnafu in hotshot_query_service::availability - Rust
Returns an iterator for traversing the chain of errors,
starting with the current error
diff --git a/hotshot_query_service/availability/struct.InvalidTransactionIndexSnafu.html b/hotshot_query_service/availability/struct.InvalidTransactionIndexSnafu.html
index 3395a5ad5..dcf5d8816 100644
--- a/hotshot_query_service/availability/struct.InvalidTransactionIndexSnafu.html
+++ b/hotshot_query_service/availability/struct.InvalidTransactionIndexSnafu.html
@@ -1,17 +1,17 @@
-InvalidTransactionIndexSnafu in hotshot_query_service::availability - Rust
If data needed to respond to a request is missing, it can (in some cases) be fetched from an
+external provider. This parameter controls how long the request handler will wait for
+missing data to be fetched before giving up and failing the request.
Convert Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>. Box<dyn Any> can
+then be further downcast into Box<ConcreteType> where ConcreteType implements Trait.
Convert Arc<Trait> (where Trait: Downcast) to Arc<Any>. Arc<Any> can then be
+further downcast into Arc<ConcreteType> where ConcreteType implements Trait.
Set the foreground color at runtime. Only use if you do not know which color will be used at
+compile-time. If the color is constant, use either OwoColorize::fg or
+a color-specific method, such as OwoColorize::green, Read more
Set the background color at runtime. Only use if you do not know what color to use at
+compile-time. If the color is constant, use either OwoColorize::bg or
+a color-specific method, such as OwoColorize::on_yellow, Read more
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/fetching/index.html b/hotshot_query_service/data_source/fetching/index.html
new file mode 100644
index 000000000..4efe981c8
--- /dev/null
+++ b/hotshot_query_service/data_source/fetching/index.html
@@ -0,0 +1,51 @@
+hotshot_query_service::data_source::fetching - Rust
FetchingDataSource combines a local storage implementation with a remote data availability
+provider to create a data sources which caches data locally, but which is capable of fetching
+missing data from a remote source, either proactively or on demand.
+
This implementation supports three kinds of data fetching.
Proactive fetching means actively scanning the local database for missing objects and
+proactively retrieving them from a remote provider, even if those objects have yet to be
+requested by a client. Doing this increases the chance of success and decreases latency when a
+client does eventually ask for those objects. This is also the mechanism by which a query
+service joining a network late, or having been offline for some time, is able to catch up with
+the events on the network that it missed.
+
The current implementation of proactive fetching is meant to be the simplest effective algorithm
+which still gives us a reasonable range of configuration options for experimentation. It is
+subject to change as we learn about the behavior of proactive fetching in a realistic system.
+
Proactive fetching is currently implemented by a background task which performs periodic scans
+of the database, identifying and retrieving missing objects. This task is generally low
+priority, since missing objects are rare, and it will take care not to monopolize resources that
+could be used to serve requests. To reduce load and to optimize for the common case where blocks
+are usually not missing once they have already been retrieved, we distinguish between major
+and minor scans.
+
Minor scans are lightweight and can run very frequently. They will only look for missing
+blocks among blocks that are new since the previous scan. Thus, the more frequently minor
+scans run, the less work they have to do. This allows them to run frequently, giving low
+latency for retrieval of newly produced blocks that we failed to receive initially. Between
+each minor scan, the task will sleep for a configurable
+duration to wait for new blocks to be produced and give
+other tasks full access to all shared resources.
+
Every nth scan (n is configurable) is a major scan.
+These scan all blocks from 0, which guarantees that we will eventually retrieve all blocks, even
+if for some reason we have lost a block that we previously had (due to storage failures and
+corruptions, or simple bugs in this software). These scans are rather expensive (although they
+will release control of shared resources many times during the duration of the scan), but
+because it is rather unlikely that a major scan will discover any missing blocks that the next
+minor scan would have missed, it is ok if major scans run very infrequently.
Active fetching means reaching out to a remote data availability provider to retrieve a missing
+resource, upon receiving a request for that resource from a client. Not every request for a
+missing resource triggers an active fetch. To avoid spamming peers with requests for missing
+data, we only actively fetch resources that are known to exist somewhere. This means we can
+actively fetch leaves and headers when we are requested a leaf or header by height, whose height
+is less than the current chain height. We can fetch a block when the corresponding header exists
+(corresponding based on height, hash, or payload hash) or can be actively fetched.
For requests that cannot be actively fetched (for example, a block requested by hash, where we
+do not have a header proving that a block with that hash exists), we use passive fetching. This
+essentially means waiting passively until the query service receives an object that satisfies
+the request. This object may be received because it was actively fetched in responsive to a
+different request for the same object, one that permitted an active fetch. Or it may have been
+fetched proactively.
A provider which can be used as a fetcher by the availability service.
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/fetching/sidebar-items.js b/hotshot_query_service/data_source/fetching/sidebar-items.js
new file mode 100644
index 000000000..1e099aed8
--- /dev/null
+++ b/hotshot_query_service/data_source/fetching/sidebar-items.js
@@ -0,0 +1 @@
+window.SIDEBAR_ITEMS = {"enum":["BlockRequest"],"struct":["Builder","FetchingDataSource","StorageReadGuard","StorageWriteGuard"],"trait":["AvailabilityProvider"]};
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/fetching/struct.Builder.html b/hotshot_query_service/data_source/fetching/struct.Builder.html
new file mode 100644
index 000000000..f578d2612
--- /dev/null
+++ b/hotshot_query_service/data_source/fetching/struct.Builder.html
@@ -0,0 +1,175 @@
+Builder in hotshot_query_service::data_source::fetching - Rust
Set the number of items to process at a time when scanning for proactive fetching.
+
This is similar to Self::with_range_chunk_size, but only affects the chunk size for
+proactive fetching scans, not for normal subscription streams. This can be useful to tune
+the proactive scanner to be more or less greedy with the lock on persistent storage.
+
By default (i.e. if this method is not called) the proactive range chunk size will be set to
+whatever the normal range chunk size is.
This can reduce load on the CPU and the database, but increases the probability that
+requests will fail due to missing resources. If resources are constrained, it is recommended
+to run with rare proactive fetching (see
+with_major_scan_interval,
+with_minor_scan_interval), rather than disabling it
+entirely.
Convert Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>. Box<dyn Any> can
+then be further downcast into Box<ConcreteType> where ConcreteType implements Trait.
Convert Arc<Trait> (where Trait: Downcast) to Arc<Any>. Arc<Any> can then be
+further downcast into Arc<ConcreteType> where ConcreteType implements Trait.
Set the foreground color at runtime. Only use if you do not know which color will be used at
+compile-time. If the color is constant, use either OwoColorize::fg or
+a color-specific method, such as OwoColorize::green, Read more
Set the background color at runtime. Only use if you do not know what color to use at
+compile-time. If the color is constant, use either OwoColorize::bg or
+a color-specific method, such as OwoColorize::on_yellow, Read more
A data source is constructed modularly by combining a storage implementation
+with a Fetcher. The former allows the query service to store the
+data it has persistently in an easily accessible storage medium, such as the local file system
+or a database. This allows it to answer queries efficiently and to maintain its state across
+restarts. The latter allows the query service to fetch data that is missing from its storage
+from an external data availability provider, such as the Tiramisu DA network or another instance
+of the query service.
+
These two components of a data source are combined in FetchingDataSource, which is the
+lowest level kind of data source available. It simply uses the storage implementation to fetch
+data when available, and fills in everything else using the fetcher. Various kinds of data
+sources can be constructed out of FetchingDataSource by changing the storage and fetcher
+implementations used, and more complex data sources can be built on top using data source
+combinators.
If there is existing data corresponding to the FileSystemDataSource data structures, it
+will be archived.
+
The FileSystemDataSource will register its persistent data structures with loader. The
+caller is responsible for creating an AtomicStore from loader
+and managing synchronization of the store.
If there is no existing data corresponding to the FileSystemDataSource data structures, a
+new store will be created.
+
The FileSystemDataSource will register its persistent data structures with loader. The
+caller is responsible for creating an AtomicStore from loader
+and managing synchronization of the store.
Access the transaction which is accumulating all uncommitted changes to the data source.
+
This can be used to manually group database modifications to custom state atomically with
+modifications made through the SqlDataSource.
+
If there is no currently open transaction, a new transaction will be opened. No changes
+made through the transaction objeect returned by this method will be persisted until
+commit is called.
Convert Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>. Box<dyn Any> can
+then be further downcast into Box<ConcreteType> where ConcreteType implements Trait.
Convert Arc<Trait> (where Trait: Downcast) to Arc<Any>. Arc<Any> can then be
+further downcast into Arc<ConcreteType> where ConcreteType implements Trait.
Set the foreground color at runtime. Only use if you do not know which color will be used at
+compile-time. If the color is constant, use either OwoColorize::fg or
+a color-specific method, such as OwoColorize::green, Read more
Set the background color at runtime. Only use if you do not know what color to use at
+compile-time. If the color is constant, use either OwoColorize::bg or
+a color-specific method, such as OwoColorize::on_yellow, Read more
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/fetching/struct.StorageReadGuard.html b/hotshot_query_service/data_source/fetching/struct.StorageReadGuard.html
new file mode 100644
index 000000000..7cb257d2f
--- /dev/null
+++ b/hotshot_query_service/data_source/fetching/struct.StorageReadGuard.html
@@ -0,0 +1,138 @@
+StorageReadGuard in hotshot_query_service::data_source::fetching - Rust
Convert Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>. Box<dyn Any> can
+then be further downcast into Box<ConcreteType> where ConcreteType implements Trait.
Convert Arc<Trait> (where Trait: Downcast) to Arc<Any>. Arc<Any> can then be
+further downcast into Arc<ConcreteType> where ConcreteType implements Trait.
Set the foreground color at runtime. Only use if you do not know which color will be used at
+compile-time. If the color is constant, use either OwoColorize::fg or
+a color-specific method, such as OwoColorize::green, Read more
Set the background color at runtime. Only use if you do not know what color to use at
+compile-time. If the color is constant, use either OwoColorize::bg or
+a color-specific method, such as OwoColorize::on_yellow, Read more
impl<T> Parsable for Twhere
+ T: Deref,
+ <T as Deref>::Target: Parsable,
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/fetching/struct.StorageWriteGuard.html b/hotshot_query_service/data_source/fetching/struct.StorageWriteGuard.html
new file mode 100644
index 000000000..6145438f8
--- /dev/null
+++ b/hotshot_query_service/data_source/fetching/struct.StorageWriteGuard.html
@@ -0,0 +1,139 @@
+StorageWriteGuard in hotshot_query_service::data_source::fetching - Rust
Convert Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>. Box<dyn Any> can
+then be further downcast into Box<ConcreteType> where ConcreteType implements Trait.
Convert Arc<Trait> (where Trait: Downcast) to Arc<Any>. Arc<Any> can then be
+further downcast into Arc<ConcreteType> where ConcreteType implements Trait.
Set the foreground color at runtime. Only use if you do not know which color will be used at
+compile-time. If the color is constant, use either OwoColorize::fg or
+a color-specific method, such as OwoColorize::green, Read more
Set the background color at runtime. Only use if you do not know what color to use at
+compile-time. If the color is constant, use either OwoColorize::bg or
+a color-specific method, such as OwoColorize::on_yellow, Read more
impl<T> Parsable for Twhere
+ T: Deref,
+ <T as Deref>::Target: Parsable,
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/fetching/trait.AvailabilityProvider.html b/hotshot_query_service/data_source/fetching/trait.AvailabilityProvider.html
new file mode 100644
index 000000000..9d935ac70
--- /dev/null
+++ b/hotshot_query_service/data_source/fetching/trait.AvailabilityProvider.html
@@ -0,0 +1,3 @@
+AvailabilityProvider in hotshot_query_service::data_source::fetching - Rust
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/index.html b/hotshot_query_service/data_source/index.html
index a21c60c37..15d9173af 100644
--- a/hotshot_query_service/data_source/index.html
+++ b/hotshot_query_service/data_source/index.html
@@ -1,11 +1,11 @@
-hotshot_query_service::data_source - Rust
Persistent storage and sources of data consumed by APIs.
The APIs provided by this query service are generic over the implementation which actually
retrieves data in answer to queries. We call this implementation a data source. This module
defines a data source and provides several pre-built implementations:
A data source for the APIs provided in this crate, backed by the local file system.
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/sidebar-items.js b/hotshot_query_service/data_source/sidebar-items.js
index 98aa40452..2d5309aaa 100644
--- a/hotshot_query_service/data_source/sidebar-items.js
+++ b/hotshot_query_service/data_source/sidebar-items.js
@@ -1 +1 @@
-window.SIDEBAR_ITEMS = {"mod":["sql","storage"],"struct":["ExtensibleDataSource","FetchingDataSource","MetricsDataSource"],"trait":["UpdateDataSource","VersionedDataSource"],"type":["FileSystemDataSource"]};
\ No newline at end of file
+window.SIDEBAR_ITEMS = {"mod":["fetching","sql","storage"],"struct":["ExtensibleDataSource","MetricsDataSource"],"trait":["UpdateDataSource","VersionedDataSource"],"type":["FileSystemDataSource"]};
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/sql/index.html b/hotshot_query_service/data_source/sql/index.html
index 7d59aa029..3b73226a5 100644
--- a/hotshot_query_service/data_source/sql/index.html
+++ b/hotshot_query_service/data_source/sql/index.html
@@ -1,3 +1,3 @@
-hotshot_query_service::data_source::sql - Rust
Represents a schema migration to be run on the database,
this struct is used by the embed_migrations! macro to gather migration files
-and shouldn’t be needed by the user
A data source for the APIs provided in this crate, backed by a remote PostgreSQL database.
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/sql/sidebar-items.js b/hotshot_query_service/data_source/sql/sidebar-items.js
index a5a90d6e3..feadd0a2c 100644
--- a/hotshot_query_service/data_source/sql/sidebar-items.js
+++ b/hotshot_query_service/data_source/sql/sidebar-items.js
@@ -1 +1 @@
-window.SIDEBAR_ITEMS = {"macro":["include_migrations"],"struct":["Error","Migration"],"type":["SqlDataSource"]};
\ No newline at end of file
+window.SIDEBAR_ITEMS = {"macro":["include_migrations"],"struct":["Error","Migration"],"type":["Builder","SqlDataSource"]};
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/sql/type.Builder.html b/hotshot_query_service/data_source/sql/type.Builder.html
new file mode 100644
index 000000000..9c6e6fa9e
--- /dev/null
+++ b/hotshot_query_service/data_source/sql/type.Builder.html
@@ -0,0 +1 @@
+Builder in hotshot_query_service::data_source::sql - Rust
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/sql/type.SqlDataSource.html b/hotshot_query_service/data_source/sql/type.SqlDataSource.html
index d6d71720d..d9f509654 100644
--- a/hotshot_query_service/data_source/sql/type.SqlDataSource.html
+++ b/hotshot_query_service/data_source/sql/type.SqlDataSource.html
@@ -1,4 +1,4 @@
-SqlDataSource in hotshot_query_service::data_source::sql - Rust
This data source will automatically connect to and perform queries on a remote SQL database.
However, administration of the database, such as initialization, resetting, and backups, is
@@ -92,7 +92,7 @@
Internally, the data source maintains an open Transaction whenever there are outstanding
changes, and commits the transaction on commit. The
-underlying database transaction can be accessed directly via transaction,
+underlying database transaction can be accessed directly via transaction,
which makes it possible to compose application-specific database updates atomically with updates
made by the SqlDataSource itself. This is useful for extension and
composition.
is more involved, but still possible. Follow the steps for
custom migrations to modify the database schema to account for the new
data you want to store. You can then access this data through the SqlDataSource using
-query to run a custom read-only SQL query or transaction
+query to run a custom read-only SQL query or transaction
to execute a custom atomic mutation of the database. If you use
-transaction, be sure to call
+transaction, be sure to call
commit when you are ready to persist your changes.
-
You will typically use query to read custom data in API endpoint handlers and
-transaction to populate custom data in your web server’s update loop.
+
You will typically use query to read custom data in API endpoint handlers and
+transaction to populate custom data in your web server’s update loop.
Composing SqlDataSource with other module states is fairly simple – just
create an aggregate struct containing both SqlDataSource and your additional module
states, as described in the composition guide. If the additional modules
have data that should live in the same database as the SqlDataSource data, you can follow
the steps in custom migrations to accomodate this. When modifying that
-data, you can use transaction to atomically synchronize updates to the
+data, you can use transaction to atomically synchronize updates to the
other modules’ data with updates to the SqlDataSource. If the additional data is completely
independent of HotShot query service data and does not need to be synchronized, you can also
connect to the database directly to make updates.
In the following example, we compose HotShot query service modules with other application-
-specific modules, synchronizing updates using transaction.
+specific modules, synchronizing updates using transaction.
Access the transaction which is accumulating all uncommitted changes to the data source.
This can be used to manually group database modifications to custom state atomically with
modifications made through the SqlDataSource.
If there is no currently open transaction, a new transaction will be opened. No changes
made through the transaction objeect returned by this method will be persisted until
commit is called.
Naturally, an archival query service such as this is heavily dependent on a persistent storage
implementation. This module defines the interfaces required of this storage. Any storage layer
implementing the appropriate interfaces can be used as the storage layer when constructing a
-FetchingDataSource, which can in turn be used to instantiate the
+FetchingDataSource, which can in turn be used to instantiate the
REST APIs provided by this crate.
This module also comes with a few pre-built persistence implementations:
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/storage/sql/struct.Config.html b/hotshot_query_service/data_source/storage/sql/struct.Config.html
index bf7f10838..9dd531f29 100644
--- a/hotshot_query_service/data_source/storage/sql/struct.Config.html
+++ b/hotshot_query_service/data_source/storage/sql/struct.Config.html
@@ -1,10 +1,17 @@
-Config in hotshot_query_service::data_source::storage::sql - Rust
The results will reflect the state after the statements thus far added to this transaction have
been applied, even though those effects have not been committed to the database yet.
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/storage/trait.AvailabilityStorage.html b/hotshot_query_service/data_source/storage/trait.AvailabilityStorage.html
index 886334cfb..4ada870a1 100644
--- a/hotshot_query_service/data_source/storage/trait.AvailabilityStorage.html
+++ b/hotshot_query_service/data_source/storage/trait.AvailabilityStorage.html
@@ -1,4 +1,4 @@
-AvailabilityStorage in hotshot_query_service::data_source::storage - Rust
A data source is constructed modularly by combining a storage implementation
-with a Fetcher. The former allows the query service to store the
-data it has persistently in an easily accessible storage medium, such as the local file system
-or a database. This allows it to answer queries efficiently and to maintain its state across
-restarts. The latter allows the query service to fetch data that is missing from its storage
-from an external data availability provider, such as the Tiramisu DA network or another instance
-of the query service.
-
These two components of a data source are combined in FetchingDataSource, which is the
-lowest level kind of data source available. It simply uses the storage implementation to fetch
-data when available, and fills in everything else using the fetcher. Various kinds of data
-sources can be constructed out of FetchingDataSource by changing the storage and fetcher
-implementations used, and more complex data sources can be built on top using data source
-combinators.
If there is existing data corresponding to the FileSystemDataSource data structures, it
-will be archived.
-
The FileSystemDataSource will register its persistent data structures with loader. The
-caller is responsible for creating an AtomicStore from loader
-and managing synchronization of the store.
If there is no existing data corresponding to the FileSystemDataSource data structures, a
-new store will be created.
-
The FileSystemDataSource will register its persistent data structures with loader. The
-caller is responsible for creating an AtomicStore from loader
-and managing synchronization of the store.
Access the transaction which is accumulating all uncommitted changes to the data source.
-
This can be used to manually group database modifications to custom state atomically with
-modifications made through the SqlDataSource.
-
If there is no currently open transaction, a new transaction will be opened. No changes
-made through the transaction objeect returned by this method will be persisted until
-commit is called.
Convert Box<dyn Trait> (where Trait: Downcast) to Box<dyn Any>. Box<dyn Any> can
-then be further downcast into Box<ConcreteType> where ConcreteType implements Trait.
Convert Arc<Trait> (where Trait: Downcast) to Arc<Any>. Arc<Any> can then be
-further downcast into Arc<ConcreteType> where ConcreteType implements Trait.
Set the foreground color at runtime. Only use if you do not know which color will be used at
-compile-time. If the color is constant, use either OwoColorize::fg or
-a color-specific method, such as OwoColorize::green, Read more
Set the background color at runtime. Only use if you do not know what color to use at
-compile-time. If the color is constant, use either OwoColorize::bg or
-a color-specific method, such as OwoColorize::on_yellow, Read more
\ No newline at end of file
diff --git a/hotshot_query_service/data_source/trait.VersionedDataSource.html b/hotshot_query_service/data_source/trait.VersionedDataSource.html
index 21946f8ff..28911c530 100644
--- a/hotshot_query_service/data_source/trait.VersionedDataSource.html
+++ b/hotshot_query_service/data_source/trait.VersionedDataSource.html
@@ -39,7 +39,7 @@
changes to the database is considered a fatal error, and this function may panic.
A data source for the APIs provided in this crate, backed by the local file system.
Synchronization and atomicity of persisted data structures are provided via [atomic_store].
The methods commit,
-revert, and skip_version of this
+revert, and skip_version of this
type can be used to control synchronization in the underlying
AtomicStore.
their own persistent state, should the storage of FileSystemDataSource and the other modules
be completely independent, or synchronized under the control of a single
AtomicStore? FileSystemDataSource supports both patterns:
-when you create it with create or open, it will open its own
+when you create it with create or open, it will open its own
AtomicStore and manage the synchronization of its own storage,
independent of any other persistent data it might be composed with. But when you create it with
-create_with_store or open_with_store,
+create_with_store or open_with_store,
you may ask it to register its persistent data structures with an existing
[AtomicStoreLoader]. If you register other modules’ persistent data structures with the same
loader, you can create one AtomicStore that synchronizes all the
persistent data. Note, though, that when you choose to use
-create_with_store or open_with_store,
+create_with_store or open_with_store,
you become responsible for ensuring that calls to
AtomicStore::commit_version alternate with calls
to commit or
@@ -87,15 +87,15 @@
The FileSystemDataSource will register its persistent data structures with loader. The
caller is responsible for creating an AtomicStore from loader
and managing synchronization of the store.
The FileSystemDataSource will register its persistent data structures with loader. The
caller is responsible for creating an AtomicStore from loader
and managing synchronization of the store.
Advance the version of the persistent store without committing changes to persistent state.
This function is useful when the AtomicStore synchronizing
storage for this FileSystemDataSource is being managed by the caller. The caller may want
to persist some changes to other modules whose state is managed by the same
@@ -121,5 +121,5 @@
Returns an iterator for traversing the chain of errors,
starting with the current error
-and continuing with recursive calls to Error::source. Read more
For maximum effectiveness, this needs to be called as a method
diff --git a/hotshot_query_service/enum.QueryError.html b/hotshot_query_service/enum.QueryError.html
index 5dcb5299c..e0604bf77 100644
--- a/hotshot_query_service/enum.QueryError.html
+++ b/hotshot_query_service/enum.QueryError.html
@@ -1,4 +1,4 @@
-QueryError in hotshot_query_service - Rust
Returns an iterator for traversing the chain of errors,
starting with the current error
-and continuing with recursive calls to Error::source. Read more
For maximum effectiveness, this needs to be called as a method
diff --git a/hotshot_query_service/fetching/provider/struct.AnyProvider.html b/hotshot_query_service/fetching/provider/struct.AnyProvider.html
index 19903e419..e20ec51ea 100644
--- a/hotshot_query_service/fetching/provider/struct.AnyProvider.html
+++ b/hotshot_query_service/fetching/provider/struct.AnyProvider.html
@@ -1,4 +1,4 @@
-AnyProvider in hotshot_query_service::fetching::provider - Rust
Adaptor combining multiple data availability providers.
This provider adaptor implements the Provider protocol by fetching
requested objects from several different underlying providers. If any of the underlying sources
@@ -171,5 +171,7 @@
\ No newline at end of file
diff --git a/hotshot_query_service/fetching/provider/struct.NoFetching.html b/hotshot_query_service/fetching/provider/struct.NoFetching.html
index 52d2c5fbf..3a8fc346c 100644
--- a/hotshot_query_service/fetching/provider/struct.NoFetching.html
+++ b/hotshot_query_service/fetching/provider/struct.NoFetching.html
@@ -1,4 +1,4 @@
-NoFetching in hotshot_query_service::fetching::provider - Rust
\ No newline at end of file
diff --git a/hotshot_query_service/fetching/provider/struct.QueryServiceProvider.html b/hotshot_query_service/fetching/provider/struct.QueryServiceProvider.html
index 39d1270c6..1fbb4a670 100644
--- a/hotshot_query_service/fetching/provider/struct.QueryServiceProvider.html
+++ b/hotshot_query_service/fetching/provider/struct.QueryServiceProvider.html
@@ -1,4 +1,4 @@
-QueryServiceProvider in hotshot_query_service::fetching::provider - Rust
Data availability provider backed by another instance of this query service.
This fetcher implements the Provider interface by querying the REST API provided by another
instance of this query service to try and retrieve missing objects.
\ No newline at end of file
diff --git a/hotshot_query_service/fetching/request/struct.LeafRequest.html b/hotshot_query_service/fetching/request/struct.LeafRequest.html
index 8d3d0f8b5..86dc460b1 100644
--- a/hotshot_query_service/fetching/request/struct.LeafRequest.html
+++ b/hotshot_query_service/fetching/request/struct.LeafRequest.html
@@ -1,16 +1,16 @@
LeafRequest in hotshot_query_service::fetching::request - Rust
The HotShot Query Service is a minimal, generic query service that can be integrated into any
decentralized application running on the [hotshot] consensus layer. It provides all the features
that HotShot itself expects of a query service (such as providing consensus-related data for
catchup and synchronization) as well as some application-level features that deal only with
diff --git a/hotshot_query_service/macro.instantiate_data_source_tests.html b/hotshot_query_service/macro.instantiate_data_source_tests.html
index fb7441055..788a9ac1b 100644
--- a/hotshot_query_service/macro.instantiate_data_source_tests.html
+++ b/hotshot_query_service/macro.instantiate_data_source_tests.html
@@ -1,3 +1,3 @@
-
instantiate_data_source_tests in hotshot_query_service - Rust
Returns an iterator for traversing the chain of errors,
starting with the current error
diff --git a/hotshot_query_service/metrics/struct.PrometheusMetrics.html b/hotshot_query_service/metrics/struct.PrometheusMetrics.html
index 77f2bf9b8..0c00ecbdd 100644
--- a/hotshot_query_service/metrics/struct.PrometheusMetrics.html
+++ b/hotshot_query_service/metrics/struct.PrometheusMetrics.html
@@ -24,7 +24,7 @@
) -> Result<PrometheusMetrics, MetricsError>where
I: IntoIterator,
I::Item: AsRef<str>,
Get a (possibly nested) subgroup of this group by its path.
Returns an iterator for traversing the chain of errors,
starting with the current error
-and continuing with recursive calls to Error::source. Read more
For maximum effectiveness, this needs to be called as a method
diff --git a/hotshot_query_service/node/trait.NodeDataSource.html b/hotshot_query_service/node/trait.NodeDataSource.html
index f7db68968..445dd2087 100644
--- a/hotshot_query_service/node/trait.NodeDataSource.html
+++ b/hotshot_query_service/node/trait.NodeDataSource.html
@@ -41,7 +41,7 @@
D: NodeDataSource<Types> + Send + Sync,
U: Send + Sync,
Types: NodeType,source§
Returns an iterator for traversing the chain of errors,
starting with the current error
diff --git a/hotshot_query_service/status/trait.StatusDataSource.html b/hotshot_query_service/status/trait.StatusDataSource.html
index 12cc277d2..63fec8ba1 100644
--- a/hotshot_query_service/status/trait.StatusDataSource.html
+++ b/hotshot_query_service/status/trait.StatusDataSource.html
@@ -33,7 +33,7 @@
Self: Sync + 'async_trait,
'life0: 'async_trait,
\ No newline at end of file
diff --git a/hotshot_query_service/struct.MissingSnafu.html b/hotshot_query_service/struct.MissingSnafu.html
index dbda82e31..bd1f8115d 100644
--- a/hotshot_query_service/struct.MissingSnafu.html
+++ b/hotshot_query_service/struct.MissingSnafu.html
@@ -1,8 +1,8 @@
-MissingSnafu in hotshot_query_service - Rust