Table of Contents

Class GetDatasetConditionParams

Namespace
DatabentoDotNet.Historical
Assembly
DatabentoDotNet.Historical.dll

The parameters for metadata.get_dataset_condition, which reports data availability and quality for a dataset.

public sealed record GetDatasetConditionParams : IEquatable<GetDatasetConditionParams>
Inheritance
GetDatasetConditionParams
Implements
Inherited Members

Remarks

Port of upstream's GetDatasetConditionParams (metadata.rs:280-289).

Properties

Dataset

The dataset code, for example XNAS.ITCH.

public required string Dataset { get; init; }

Property Value

string

DateRange

The UTC date range to report on, or null to report on every available date. This is the library's own DateRange and its usual half-open contract holds: an inclusive Start, an exclusive End, and n days requested is n details returned. DateRange.OnDay(d) reports on d alone.

public DateRange? DateRange { get; init; }

Property Value

DateRange?

Remarks

The endpoint itself disagrees, and the difference is absorbed in ToQueryParameters(). get_dataset_condition reads end_date as inclusive — verified against the real API by #44, which is the question this property's doc comment used to defer. So the renderer sends the day before End, via ToInclusiveEndDateParameters(DateRange), and the caller's half-open range means here what it means everywhere else (#45).

This diverges from every other Databento client, deliberately. Upstream's DateRange is half-open too — From<RangeInclusive> normalizes with next_day() (historical.rs:72-79) — and its one AddToQuery<DateRange> sends end verbatim to every endpoint, so databento-rs carries the identical off-by-one and documents the consequence at this field instead of correcting it (metadata.rs:285). databento-cpp offers no opinion at all: its DateRange is a pair of raw strings the caller writes out. Correcting it here is the same call this library already made about empty ranges, about decimal over f64, and about a sub-day Spanning — and it loses nothing, because a caller who genuinely wants d and d + 1 writes DateRange.Including(d, d.PlusDays(1)).

The rejected alternative was a second, closed-range type for this one endpoint, so the difference would sit in the caller's source rather than in a renderer. It was rejected on price: a public type every caller must learn to choose between, permanently, to describe one server's reading of one parameter on one endpoint. What settled it was probing metadata.list_datasets, the only other endpoint taking this type today: upstream documents nothing about its end (metadata.rs:41-50) and against the real API it is genuinely half-open. So the difference belongs to this endpoint, not to the library's model of a date range, and it is rendered where it belongs.

Methods

ToQueryParameters()

Renders this parameter set as the query string the get_dataset_condition endpoint's GET request carries.

public IReadOnlyList<KeyValuePair<string, string>> ToQueryParameters()

Returns

IReadOnlyList<KeyValuePair<string, string>>

The query parameters, in upstream's push order.

Remarks

The order matches upstream: dataset is always sent first (metadata.rs:125-127), and start_date/end_date follow only when DateRange is set (metadata.rs:128-130).

The renderer is ToInclusiveEndDateParameters(DateRange), not the ToExclusiveEndDateParameters(DateRange) that ListDatasetsAsync(DateRange?, CancellationToken) uses — this endpoint reads end_date as inclusive and that one does not. Both live side by side on DateRange so the difference is one line of one file rather than an arithmetic adjustment buried in a parameter list here; see the DateRange property above for why the conversion happens at all.

Exceptions

InvalidOperationException

DateRange is set to a default DateRange value — reachable even though every factory on that type rejects one, because new DateRange() uses the struct's implicit parameterless constructor, which C# cannot suppress. ToInclusiveEndDateParameters(DateRange) guards against one explicitly rather than leaning on StartIsoDate being evaluated first, since it formats End minus a day rather than reading EndIsoDate.

Edit this page