Summary
The samplestore currently exposes multiple methods for fetching entities by identifier. Two of these are legacy lookup paths that bypass the shared entity/measurement cache and are redundant now that get_entities covers their use cases. The proposal is to redirect all internal entity-fetching through get_entities and mark the legacy methods as deprecated, so callers are guided toward the canonical API without introducing any breaking changes.
Motivation
Having parallel fetch paths makes the codebase harder to reason about and maintain. The legacy methods reach the database directly, bypassing caching logic that get_entities manages centrally. Consolidating on a single path reduces duplication, improves cache consistency, and makes future optimisations easier to apply in one place. Soft-deprecating rather than removing the methods keeps full backwards compatibility while signalling the preferred direction to downstream users.
Scope
- Samplestore implementation — internal callers should be updated to use
get_entities directly; the legacy methods should then be turned into thin, warning-emitting wrappers that delegate to get_entities rather than hitting the database themselves
- Samplestore base/abstract layer — the abstract declarations of the legacy methods should be annotated as deprecated so any alternative implementations surface the same guidance
- Operator layer — internal usages of the legacy lookup should be redirected to
get_entities
- Tests — existing tests that call the legacy methods directly should be updated to assert that a deprecation warning is emitted, while keeping all existing return-value assertions intact
Summary
The samplestore currently exposes multiple methods for fetching entities by identifier. Two of these are legacy lookup paths that bypass the shared entity/measurement cache and are redundant now that
get_entitiescovers their use cases. The proposal is to redirect all internal entity-fetching throughget_entitiesand mark the legacy methods as deprecated, so callers are guided toward the canonical API without introducing any breaking changes.Motivation
Having parallel fetch paths makes the codebase harder to reason about and maintain. The legacy methods reach the database directly, bypassing caching logic that
get_entitiesmanages centrally. Consolidating on a single path reduces duplication, improves cache consistency, and makes future optimisations easier to apply in one place. Soft-deprecating rather than removing the methods keeps full backwards compatibility while signalling the preferred direction to downstream users.Scope
get_entitiesdirectly; the legacy methods should then be turned into thin, warning-emitting wrappers that delegate toget_entitiesrather than hitting the database themselvesget_entities