Class DatabentoLiveBuilder
- Namespace
- DatabentoDotNet.Extensions.Hosting
- Assembly
- DatabentoDotNet.Extensions.Hosting.dll
Configures one named live session. Returned by AddDatabentoLive.
public sealed class DatabentoLiveBuilder
- Inheritance
-
DatabentoLiveBuilder
- Inherited Members
Fields
DefaultSessionName
The name the no-argument AddDatabentoLive overload uses: Default.
public const string DefaultSessionName = "Default"
Field Value
Remarks
A literal name rather than an empty one, so the configuration path is
Databento:Live:{name} in every case. The alternative — the single session's keys
directly under Databento:Live and named ones beneath it — makes
Databento:Live:Dataset and Databento:Live:equities siblings of different
kinds, which is ambiguous to read and worse to report an error against.
Properties
Name
The session's name, which is also its configuration key and its service key.
public string Name { get; }
Property Value
Services
The collection this session was registered into.
public IServiceCollection Services { get; }
Property Value
Methods
AddHealthCheck(string?, HealthStatus?, IEnumerable<string>?)
Registers a LiveSessionHealthCheck reporting this session's state.
public DatabentoLiveBuilder AddHealthCheck(string? name = null, HealthStatus? failureStatus = null, IEnumerable<string>? tags = null)
Parameters
namestringThe registration's name, which is what a health-check endpoint reports. Defaults to
databento-live-{session}, so two sessions in one host produce two distinct entries without either caller naming one.failureStatusHealthStatus?What a stopped or faulted session reports. Defaults to Unhealthy; pass Degraded for a session whose loss should not take the process out of rotation.
tagsIEnumerable<string>Tags the endpoint can filter on, or null for none.
Returns
- DatabentoLiveBuilder
This builder.
Remarks
Opt-in, and that is the whole point of it living here. Nothing in
AddDatabentoLive registers a check, so a consumer who never calls this gets none —
no registration, no probe, no cost. A check installed by default would be one every
consumer's /health endpoint reports on whether or not they asked.
Registered straight into HealthCheckServiceOptions rather than through
IHealthChecksBuilder. Going through the builder would make the consumer's own
AddHealthChecks() a prerequisite — call this first and it would throw, or worse,
silently create a second registry. Configuring the options directly means the two compose
in either order, which is the same property TryAddSingleton buys for the historical
and reference clients.
The registration resolves the keyed LiveSessionRunner lazily, when the check first runs, so calling this does not build a session at registration time.
AddRecordHandler(Func<IServiceProvider, ILiveRecordHandler>)
Registers the handler this session's records are dispatched to, built by a factory.
public DatabentoLiveBuilder AddRecordHandler(Func<IServiceProvider, ILiveRecordHandler> implementationFactory)
Parameters
implementationFactoryFunc<IServiceProvider, ILiveRecordHandler>
Returns
AddRecordHandler<THandler>()
Registers the handler this session's records are dispatched to.
public DatabentoLiveBuilder AddRecordHandler<THandler>() where THandler : class, ILiveRecordHandler
Returns
Type Parameters
THandlerThe handler type. Constructed once, as a singleton.
Remarks
A singleton, and that is the dispatch contract rather than a default. A scope per record would allocate, in the one package whose reason to exist is that it does not. A handler needing scoped services opens a scope inside OnFlushAsync(CancellationToken), which is where I/O belongs anyway.