Serving through OPTIMADE

The example uses the StructureRecord and Author classes and store from Declaring, storing, and fetching records.

StoreEntryProvider bridges a store to the httk.core.EntryProvider contract: it auto-generates an OPTIMADE entry-type definition per served class from its schema (every schema-derived property named with a registered database-specific prefix, _httk_ by default), yields JSON-able records, and declares relationships for reference fields — and for exposed weak links (see Weak links) — whose target class is also served. It also serves the run family’s StrongLink provenance edges (see Strong links): the forward keys on the run records, and the derived reverse keys on every served target family:

from httk.store.backend.sql import StoreEntryProvider

provider = StoreEntryProvider(store, {"structures": StructureRecord, "authors": Author})

Handing the provider to httk-serve’s adapter_from_providers serves the database as an OPTIMADE API. httk-store does not depend on httk-serve: the provider handoff uses the httk-core contract, while httk-serve also consumes httk-store’s neutral query and store APIs. Fields with no OPTIMADE value representation (bytes, custom codecs) are not served, and rationals are served as their nearest floats. The provider is also registered (as store-db-store) for discovery through the httk.core registry.

Each served record also exposes its lineage identity as the integer property _httk_logical_id (see Record replacement and lineages), filterable like any other served field. Pass only_latest=True to StoreEntryProvider to serve only the latest row of each lineage.