Skip to main content

cf_datahive

cf_datahive owns the Data Hive write provider for CfDataHiveSinkContractV1, publishes the read-side datahive_runs service contract for first-party consumers, and exposes a local Python read/inspect API for manual inspection, owner-side tooling, and package-local validation.

For first-party package integration the boundary is strict:

  • cross-package writes go only through cf_package_contracts and injected contract slots such as CfExecutionContext.datahive_sink
  • cross-package reads go only through cf_service_contracts and the datahive_runs provider key
  • first-party packages must not import cf_datahive
  • first-party packages must not reach into cf_datahive/native/* or consume cf_datahive_cpp_* helper APIs

Boundary

  • sandcastle/cf_datahive/src/cf_datahive/cpp is the owner-side native gatekeeper for writes under workspace/data_hive
  • sandcastle/cf_datahive/src/cf_datahive/service_contract_provider.py publishes the canonical read-side datahive_runs contract for first-party consumers
  • sandcastle/cf_datahive/src/cf_datahive provides owner-side read/inspect APIs such as DataHiveClient
  • CfDataHiveSinkContractV1 in cf_package_contracts is the only supported cross-package sink interface
  • DataHiveRunsContractV1 in cf_service_contracts is the only supported cross-package read interface

First-party packages that need read-side runtime integration should resolve ProviderKey.DATAHIVE_RUNS against the canonical workspace root instead of importing cf_datahive directly.

Usage

First-party read-side integration:

from cf_service_contracts import ProviderKey, require_provider

datahive_runs = require_provider(ProviderKey.DATAHIVE_RUNS)
evidence = datahive_runs.find_latest_run(workspace_root, pipeline_id)
if evidence is not None:
  print(evidence["run_id"], evidence["manifest_status"])

Owner-side inspection workflow:

from pathlib import Path

from cf_datahive import DataHiveClient

workspace_root = Path("workspace")
client = DataHiveClient(str(workspace_root))

runs = client.list_runs("opcua_fifo_avg")
if runs:
    latest = runs[0].run_id
    manifest = client.load_manifest("opcua_fifo_avg", latest)
    table = client.read_table("opcua_fifo_avg", latest, "measurements")
    print(manifest.status, table.num_rows)

DataHiveClient, RunHandle, and StorageModePolicy remain public for owner-side workflows, but they are not a first-party integration surface.

Canonical Layout

workspace/
  data_hive/
    <pipeline_id>/
      <yyyy>/<mm>/<dd>/<session_id>/
        runs/<run_id>/manifest.json
        runs/<run_id>/artifacts/<artifact_name>
        tables/<table_name>/run_id=<run_id>/part-0000.parquet
        tables/<table_name>/_session_compacted/part-0000.parquet
        session_manifest.json
      latest.txt
      latest_session.txt
  • latest.txt stores the latest committed run_id
  • latest_session.txt stores the latest committed session_id
  • manifest.json is the run SOT for tables, artifacts, hashes, and session linkage
  • session_manifest.json is the per-session SOT for storage-mode locks
  • flat run layouts and direct data_hive/ roots outside the canonical workspace root are not supported

Local Build Notes

cf_datahive now consumes the workspace-store runtime contract instead of linking the storage backend directly. Editable builds still use the shared native dependency cache under ~/.cogniflow/cache/native/ and the standard cf_setup MSVC/CMake environment preparation.

Build caches are expected under ~/.cogniflow/cache/native/scikit-build/cf-datahive.

Guardrails

Run:

python tools/check_datahive_guardrails.py

The guardrail script hard-fails when first-party code outside sandcastle/cf_datahive:

  • imports cf_datahive
  • references removed cf_datahive_cpp_* helper APIs
  • reaches into the removed native consumer packaging surface

Testing

pip install -e "sandcastle/cf_datahive[test]"
pytest -q sandcastle/cf_datahive/tests

Published distribution name:

pip install cf-datahive

Publishing

cf_datahive still publishes the provider binary plus provider descriptor used by cf_setup and cf_pipeline_engine.

  • Workflow: .github/workflows/cf_datahive_windows_publish.yml
  • Package directory: sandcastle/cf_datahive
  • PyPI tag: cf-datahive-v<version>
  • TestPyPI tag: cf-datahive-v<version>-test

Metadata

Release files for cf-datahive 0.1.11

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for cf-datahive 0.1.11
File Size Uploaded Provenance Actions
cf_datahive-0.1.11.tar.gz 26.4 kB Without provenance Details for cf_datahive-0.1.11.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for cf-datahive 0.1.11
File Interpreter ABI Platform Actions
cf_datahive-0.1.11-cp314-cp314-win_amd64.whl CPython 3.14 CPython 3.14 Windows x86-64 Details for cf_datahive-0.1.11-cp314-cp314-win_amd64.whl

Total release size: 108.8 kB

Release files / cf_datahive-0.1.11.tar.gz

Download URL cf_datahive-0.1.11.tar.gz
Size 26.4 kB
Tags Source
SHA-256 checksum
How to use checksums
4b07d84378534aeb402e59cbdd957359cd56408b07190a6e8f9122a94a7b747e
BLAKE2b-256 checksum
How to use checksums
b8e8a2b5154f32c4486d8f35b103978db60177bfa565d4f176187a5dd7a8e5dc
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.2.0 CPython/3.14.4

Release files / cf_datahive-0.1.11-cp314-cp314-win_amd64.whl

Download URL cf_datahive-0.1.11-cp314-cp314-win_amd64.whl
Size 82.4 kB
Tags CPython 3.14 Windows x86-64
SHA-256 checksum
How to use checksums
7fb1164e77f2e4d5e31edc0870d0471ea9dde2a89c1086bbeb5d5699b6db2920
BLAKE2b-256 checksum
How to use checksums
7a6e1d370086594c2f7c0c86b0337d79ef443eac1af47b3716fa9940e3ff0667
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.2.0 CPython/3.14.4

Security for cf-datahive 0.1.11

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page