httk.optimade.backend.providers

Build a BackendAdapter from EntryProvider sources.

This is the bridge from the neutral httk-core entry-provider contract to an OPTIMADE-serving backend: it turns one or more providers into a fully wired BackendAdapter over an in-memory store, deriving the served schema, the filter handlers, and the response-field extractors from each provider’s descriptions, property keys, and records. It is httk-optimade’s only dependency on httk.core beyond the shared runtime.

Functions

adapter_from_providers(...)	Build a BackendAdapter serving the given entry providers.
providers_from_registry(→ dict[str, ...)	Return the registered entry-provider factories keyed by their registered name.

Module Contents

httk.optimade.backend.providers.adapter_from_providers(providers: collections.abc.Iterable[httk.core.EntryProvider], **options: Any) → httk.optimade.backend.adapter.BackendAdapter

Build a BackendAdapter serving the given entry providers.

Every provider’s entry_types() become served entry types (described by their EntryTypeDefinition), its property_keys() name the served subset and drive both the filter handlers (via simple_property_handlers()) and the response-field extractors, and its records() are loaded into an InMemoryStore. Every served property MUST be described by the entry type’s definition (a custom property must therefore live in an extended() definition); a ValueError names any offender. All served properties beyond id/type are marked default-response. Extra keyword options (e.g. sortable, recognized_prefixes) are forwarded to build_served_schema(); every served property is sortable-capable, since the provider’s property-key map is passed through as the source’s sort_keys.

Declared relationships (relationships()) are fully auto-wired for serving and filtering: for each entry type with declared relationships, a synthetic __rel_<related_type> id-list field is materialized on EVERY row of that entry type (an empty list when the row has no related entries of that type, so inverse set semantics are well-defined), and a '<related_type>.id' entry built with relationship_id_handler() is merged into the entry type’s derived filter-handler table (never overwriting an entry already present, mirroring how BackendAdapter respects explicitly supplied handler tables). <related_type>.id HAS ... filters — and, through the related-property resolver of translate_filter(), depth-1 relationship-property filters such as references.doi CONTAINS "10.1" — therefore work without any hand-wiring.

httk.optimade.backend.providers.providers_from_registry() → dict[str, collections.abc.Callable[Ellipsis, httk.core.EntryProvider]]

Return the registered entry-provider factories keyed by their registered name.

Resolves each factory registered via httk.core.register_entry_provider() (through httk.handlers.* self-registration) into a callable. Providers need data, so applications instantiate them: providers_from_registry()["atomistic-structures"](data).