hotdata-framework 0.10.0__tar.gz → 0.12.0__tar.gz

hotdata_framework-0.12.0/.github/dependabot.yml

@@ -0,0 +1,17 @@
+version: 2
+updates:
+  - package-ecosystem: uv
+    directory: "/"
+    schedule:
+      interval: daily
+    allow:
+      - dependency-name: hotdata
+
+  # Action pins had no watcher, which is how gh-action-pypi-publish sat at
+  # v1.13.0 until its bundled twine broke a release at upload time. Unlike the
+  # uv entry there is no `allow` filter: the point is to see every stale pin,
+  # not a chosen one.
+  - package-ecosystem: github-actions
+    directory: "/"
+    schedule:
+      interval: weekly

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/.github/workflows/publish.yml

@@ -4,9 +4,20 @@ on:
   push:
     tags:
       - 'v[0-9]*'
+  # Retry an existing tag without moving it. A publish can fail for reasons that
+  # have nothing to do with the code — a stale action pin, a PyPI outage — and
+  # with only the tag trigger the choices were to delete and re-push the tag or
+  # to burn a version number on a CI fix. Neither is a good answer to
+  # "the upload failed, run it again".
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: Existing tag to build and publish (e.g. v1.2.3)
+        required: true
+        type: string
 
 concurrency:
-  group: pypi-publish-${{ github.ref_name }}
+  group: pypi-publish-${{ inputs.tag || github.ref_name }}
   cancel-in-progress: false
 
 permissions:
@@ -16,8 +27,13 @@ jobs:
   build:
     name: Build distribution
     runs-on: ubuntu-latest
+    env:
+      # The tag being released, whether it arrived by push or by dispatch.
+      TAG: ${{ inputs.tag || github.ref_name }}
     steps:
       - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+        with:
+          ref: ${{ inputs.tag || github.ref_name }}
 
       - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6
         with:
@@ -28,11 +44,11 @@ jobs:
 
       - name: Verify tag matches pyproject version
         run: |
-          if [[ ! "$GITHUB_REF_NAME" =~ ^v[0-9] ]]; then
-            echo "Release tag '$GITHUB_REF_NAME' must start with 'v' followed by a digit (e.g. v1.0.0)" >&2
+          if [[ ! "$TAG" =~ ^v[0-9] ]]; then
+            echo "Release tag '$TAG' must start with 'v' followed by a digit (e.g. v1.0.0)" >&2
             exit 1
           fi
-          tag="${GITHUB_REF_NAME#v}"
+          tag="${TAG#v}"
           pkg_version=$(python -c "import tomllib,pathlib; print(tomllib.loads(pathlib.Path('pyproject.toml').read_text())['project']['version'])")
           if [ "$tag" != "$pkg_version" ]; then
             echo "Release tag ($tag) does not match pyproject.toml version ($pkg_version)" >&2
@@ -65,5 +81,10 @@ jobs:
           name: dist
           path: dist/
 
+      # v1.13.0's bundled twine rejects `Metadata-Version: 2.5`, which current
+      # hatchling emits: `InvalidDistribution: '2.5' is not a valid metadata
+      # version`. The build job's own `twine check --strict` passes, because it
+      # pip-installs a current twine — so the failure appears only at upload,
+      # after the tag is already public.
       - name: Publish via Trusted Publishing
-        uses: pypa/gh-action-pypi-publish@ed0c53931b1dc9bd32cbe73a98c7f6766f8a527e # v1.13.0
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/.github/workflows/release.yml

@@ -4,6 +4,15 @@ on:
   push:
     tags:
       - 'v[0-9]*'
+  # Repair the Release for a tag that already exists, without moving it. See
+  # RELEASING.md, "If a release workflow fails" — added alongside this trigger,
+  # since a capability nobody can find is not much better than not having it.
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: Existing tag to create or update a Release for (e.g. v1.2.3)
+        required: true
+        type: string
 
 permissions:
   contents: write
@@ -12,8 +21,13 @@ jobs:
   release:
     name: Create GitHub Release
     runs-on: ubuntu-latest
+    env:
+      # The tag being released, whether it arrived by push or by dispatch.
+      TAG: ${{ inputs.tag || github.ref_name }}
     steps:
       - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
+        with:
+          ref: ${{ inputs.tag || github.ref_name }}
 
       - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6
         with:
@@ -23,7 +37,7 @@ jobs:
         id: meta
         run: |
           pkg_name=$(python -c "import tomllib,pathlib; print(tomllib.loads(pathlib.Path('pyproject.toml').read_text())['project']['name'])")
-          pkg_version="${GITHUB_REF_NAME#v}"
+          pkg_version="${TAG#v}"
           echo "name=${pkg_name}" >> "$GITHUB_OUTPUT"
           echo "version=${pkg_version}" >> "$GITHUB_OUTPUT"
 
@@ -31,7 +45,7 @@ jobs:
         id: notes
         run: |
           set -euo pipefail
-          version="${GITHUB_REF_NAME#v}"
+          version="${TAG#v}"
           if [[ -f CHANGELOG.md ]]; then
             body="$(python scripts/extract-changelog.py "$version")"
           else
@@ -47,8 +61,14 @@ jobs:
       - name: Create GitHub Release
         uses: softprops/action-gh-release@da05d552573ad5aba039eaac05058a918a7bf631 # v2.2.2
         with:
-          tag_name: ${{ github.ref_name }}
+          tag_name: ${{ inputs.tag || github.ref_name }}
           name: ${{ steps.meta.outputs.name }} ${{ steps.meta.outputs.version }}
           body: ${{ steps.notes.outputs.body }}
           generate_release_notes: false
-          make_latest: true
+          # Let GitHub decide by tag date/semver rather than by run order. On a
+          # push the tag is the newest version and becomes latest; on a dispatch
+          # repairing an older tag, a newer release keeps the badge. Note `false`
+          # is not "leave alone" — it explicitly marks a release NOT latest, so
+          # gating on the event would demote the newest tag in the very case this
+          # trigger exists for: repairing its Release after a failed push run.
+          make_latest: legacy

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/CHANGELOG.md

@@ -8,60 +8,104 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [Unreleased]
 
 
+## [0.12.0] - 2026-08-11
+
+### Added
+
+- Table storage layout, both directions. `add_managed_table()` and
+  `create_managed_database()` take `partition_by` / `sorted_by`, and
+  `managed_table_layout()` reads back what was actually declared as a
+  `TableLayout`. `TablePartitionKey` and `TableSortKey` are re-exported so
+  callers need one import.
+
+  Both halves matter because a layout is fixed when the table is created and
+  there is no alter path: a table declared without one keeps that shape until it
+  is recreated and its data rewritten. So declaring is not enough — a caller has
+  to be able to confirm it took, and to refuse to load when it cannot.
+
+  `managed_table_layout()` raises `KeyError` for a table that is not declared,
+  rather than returning an empty layout. "Not there" and "declared without a
+  layout" lead to opposite decisions for a caller.
+
+  Until now this package could not express a layout at all, which is why at least
+  one consumer hand-built the HTTP request instead. The generated key models are
+  passed through rather than wrapped, so the transform vocabulary stays exactly
+  the API's.
+
+### Changed
+
+- Require `hotdata>=0.9.0,<0.10`. 0.9.0 is the first release whose models carry
+  `partition_by` / `sorted_by` on the add-table request, the create-database
+  table declarations, and the table-info response. On an older `hotdata` the
+  fields would be silently dropped by the model and the table declared without a
+  layout, returning success — which is the failure this feature exists to end.
+
+## [0.11.0] - 2026-08-11
+
+### Changed
+
+- Cap the `hotdata` dependency to the current minor (`>=0.8.0,<0.9`). This
+  package wraps a *generated* client, so an SDK minor can remove a model field
+  or a `Configuration` keyword this wrapper passes, and there is no regeneration
+  step here to surface it — an uncapped floor turns an SDK release into a break
+  in this package, in versions already published. Raise the cap deliberately
+  after running the suite against the new minor.
+
+### Removed
+
+- **Breaking:** session/sandbox support is gone. `HotdataClient` no longer accepts
+  `session_id=`, `HotdataClient.session_id` is removed, `default_session_id()` and
+  the `HOTDATA_SANDBOX` read are gone, and `list_workspaces()`,
+  `resolve_workspace_selection()` and `pick_workspace()` lose their `session_id`
+  parameter — note that loss is **positional**, so a three-argument call raises an
+  arity `TypeError` rather than an unexpected-keyword one.
+  `workspace_health_lines()` no longer emits a `sandbox` line.
+
+  **Why now.** The server stopped enforcing session scoping some time ago, so the
+  value already reached nothing. What makes removal urgent rather than tidy is
+  that the SDK is dropping the `SessionId` security scheme: against that release
+  `Configuration(session_id=...)` raises `TypeError` instead of setting a header,
+  and this package passed it unconditionally — so every `HotdataClient(...)`
+  would fail at construction. This package still pins `hotdata<0.9`, so nothing
+  is broken today; the change is what lets the cap be raised later without a
+  second breaking release.
+
+  **Migrating.** Drop `session_id=` from `HotdataClient(...)`, stop reading
+  `client.session_id`, stop setting `HOTDATA_SANDBOX`, and pass two arguments to
+  the workspace helpers. Adapters that re-export session context in their own
+  signatures — a `session_id=` parameter, a `session_id` metadata key — need to
+  remove it from theirs too, which makes their own release breaking in turn.
+
+- `hotdata_framework.http` and `default_http_retries()`. The module existed only
+  to build the `retries=` policy removed under Fixed below, and had no other
+  callers. It predates `hotdata._retry`, which supersedes it.
+
+### Fixed
+
+- A `POST` is no longer replayed because of a response status. `HotdataClient`
+  passed its own `retries=` into `Configuration`, which replaced the generated
+  SDK's policy wholesale with one listing `POST` in `allowed_methods` alongside
+  a `(502, 503, 504)` forcelist — so an intermediary timing out a long request
+  produced a silent, identical re-`POST` while the server was still working on
+  the first one. For a load that is not idempotent: the duplicate collides with
+  the write lock the original holds and is refused.
+
+  The override is removed and the SDK's own default now applies. It is the
+  policy this wrapper was reaching for — `hotdata._retry` retries a
+  *pre-response* connection reset (the stale pooled socket case, where the
+  server did no work) on any method, while leaving read timeouts and status
+  retries idempotent-only.
+
 ## [0.10.0] - 2026-08-07
 
 ### Added
 
-- `create_index(database, table, columns=..., index_type=...)` builds an index on a
-  managed table, bringing the framework client to parity with `hotdata indexes
-  create` in the CLI. It covers all three index kinds the API accepts: `"bm25"` for
-  full-text search, `"vector"` for nearest-neighbour search, and `"sorted"`.
-  Previously the framework had no index API at all and callers had to drop to the raw
-  `hotdata.IndexesApi`, which left a managed database's data loaded but not
-  searchable: full-text queries error without an index, and vector queries run at
-  full-scan speed. Like the other managed-table operations, `database` accepts a
-  name/id or an already-resolved `ManagedDatabase`. Indexing a table on a plain
-  (non-managed) connection is not covered — the CLI's `--catalog` handles that.
-
-  `index_name` is optional and defaults to `{table}_{columns}_{index_type}`, the same
-  derivation the CLI uses when `--name` is omitted, so both surfaces name the same
-  index identically. `index_type` is required, unlike the API's `"sorted"` default,
-  because the wrong kind only fails at query time.
-
-  The server builds the index as a background job whose submit call reports success
-  even when the build later fails, so `create_index` polls the job to a terminal
-  state and raises `RuntimeError` carrying the job's `error_message`. Pass
-  `wait=False` to return once the job is accepted (`status="pending"` plus a
-  `job_id`) and own the outcome check yourself, as the CLI's `--async` does;
-  `timeout_s` and `poll_interval_s` tune the wait.
-
-  Both vector-index modes are supported. Omitting `embedding_provider_id` indexes an
-  existing vector column, queried with a literal vector — and there `metric` must
-  match the distance function the query uses (`cosine`→`cosine_distance`,
-  `l2`→`l2_distance`, `dot`→`negative_dot_product`), since a mismatch silently
-  reverts to a full table scan rather than erroring. Setting
-  `embedding_provider_id` indexes a *text* column instead: the provider embeds it
-  into `output_column`, queries pass text via `vector_distance(source_col, 'query')`,
-  and the server resolves the distance function itself.
-
-  Argument combinations that the server would silently ignore raise `ValueError`
-  before any request is sent: an unknown `index_type` or `metric`, a vector index
-  with more than one column (the engine indexes only the first), and
-  `metric`/`dimensions`/`embedding_provider_id`/`output_column`/`description` on a
-  non-vector index.
-
-  Verified against `api.hotdata.dev` when this version was released: BM25 and vector
-  indexes both build and report `ready`, and a BM25 index is used by full-text
-  search. A *vector* index on a managed database was **not** picked up by the query
-  planner at that time — a matching `cosine_distance(...) ORDER BY ... LIMIT k` still
-  planned as a full scan. That reproduces with an index created by `hotdata indexes
-  create`, so it is an engine-side issue rather than a client one, but it means a
-  vector index built through this method may not yet accelerate queries.
-
-- `CreateIndexResult`, the frozen dataclass `create_index` returns, is exported from
-  `hotdata_framework` and added to the public contract surface. Its `source_column`
-  names the text column to query for a provider-backed vector index, and is `None`
-  for BM25, sorted, and plain vector indexes.
+- `create_index(database, table, columns=..., index_type=...)` builds a `bm25`,
+  `vector`, or `sorted` index on a managed table, matching `hotdata indexes create`
+  in the CLI. The build is a background job whose submit call reports success even
+  when the build later fails, so this polls the job and raises `RuntimeError` with
+  its error message; `wait=False` returns as soon as the job is accepted. Returns
+  `CreateIndexResult`, also exported.
 
 ## [0.9.0] - 2026-07-23
 

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/CONTRACT.md

@@ -21,7 +21,6 @@ The supported import surface is:
 - `workspace_health_lines`
 - `default_api_key`
 - `default_host`
-- `default_session_id`
 - `explicit_workspace_id`
 - `list_workspaces`
 - `normalize_host`
@@ -32,6 +31,9 @@ The supported import surface is:
 - `WorkspaceSelection`
 - `ManagedDatabase`
 - `ManagedTable`
+- `TableLayout`
+- `TablePartitionKey`
+- `TableSortKey`
 - `LoadManagedTableResult`
 - `CreateIndexResult`
 - `DEFAULT_SCHEMA`
@@ -43,7 +45,7 @@ Adapters should import from `hotdata_framework` and treat this surface as the st
 
 ### `HotdataClient`
 
-- Represents runtime context: API key, host, workspace, optional session.
+- Represents runtime context: API key, host, workspace.
 - `from_env()` resolves runtime context from env vars and selected workspace.
 - `execute_sql(sql)` returns `QueryResult` or raises `RuntimeError`/`TimeoutError`.
 - `get_result(result_id)` returns a ready `QueryResult` and waits for readiness when needed.
@@ -57,6 +59,8 @@ Adapters should import from `hotdata_framework` and treat this surface as the st
   adapters should pass `connection_id` when known.
 - `uploads()` returns the uploads API wrapper for parquet staging.
 - `list_managed_databases()` returns all databases via the `/databases` API.
+- `add_managed_table(...)` and `create_managed_database(...)` accept `partition_by` / `sorted_by` to declare a table's storage layout. The layout is fixed when the table is created and cannot be altered afterwards, so omitting it is permanent for that table.
+- `managed_table_layout(database, table, schema=...)` returns the declared layout as `TableLayout`. Empty lists mean no layout was declared — sound only because the table is resolved through a managed database. Raises `KeyError` when the table is not declared, keeping "absent" distinct from "declared without a layout".
 - `resolve_managed_database(name_or_id)` resolves a database by id (direct lookup) or description (list scan). A `403` from `/databases` surfaces as `RuntimeError` (forbidden, not absent), preserving the underlying `ApiException` as `__cause__`.
 - `create_managed_database(description=..., schema=..., tables=..., expires_at=...)` creates a database via the `/databases` API and optionally declares tables up front. Returns a `ManagedDatabase` (id + `default_connection_id`) sufficient to load without a further read.
 - `delete_managed_database(name_or_id)` deletes a database via the `/databases` API.
@@ -65,7 +69,7 @@ Adapters should import from `hotdata_framework` and treat this surface as the st
 - `load_managed_table(database, table, schema=..., upload_id=..., file=...)` publishes parquet data into a declared managed table.
 - `delete_managed_table(database, table, schema=...)` deletes a managed table.
 - `create_index(database, table, schema=..., columns=..., index_type=..., index_name=...)` builds a `"sorted"`, `"bm25"`, or `"vector"` index on a managed table and returns a `CreateIndexResult`. It is the framework-side equivalent of the CLI's `hotdata indexes create`; indexing a table on a plain (non-managed) connection is out of scope. `index_name` defaults to `{table}_{columns}_{index_type}`, matching the CLI's derivation when `--name` is omitted. `index_type` is required rather than defaulting to the API's `"sorted"`. The build runs as a background job; the call polls it to a terminal state and raises `RuntimeError` with the job's `error_message` when it fails, because the submit call reports success regardless. `wait=False` returns as soon as the job is accepted, with `status="pending"` and a `job_id` for the caller to poll. For `index_type="vector"`, omitting `embedding_provider_id` indexes an existing vector column and `metric` (`"l2"`, `"cosine"`, `"dot"`) selects the distance function the index accelerates — a query using a different function silently falls back to a full scan; setting `embedding_provider_id` indexes a source *text* column instead, and the returned `source_column` names the column to pass to `vector_distance`. Argument combinations the server would silently ignore raise `ValueError` before any request is sent.
-- The `database` argument of `list_managed_tables`, `load_managed_table`, `add_managed_table`, `delete_managed_table`, `delete_managed_database`, `create_index`, and `execute_sql` accepts a name/id **or** an already-resolved `ManagedDatabase`. Passing a `ManagedDatabase` skips the name/id read probe, so a create-scoped key that cannot read `/databases` can load into a database it just created.
+- The `database` argument of `list_managed_tables`, `load_managed_table`, `add_managed_table`, `delete_managed_table`, `delete_managed_database`, `create_index`, `managed_table_layout`, and `execute_sql` accepts a name/id **or** an already-resolved `ManagedDatabase`. Passing a `ManagedDatabase` skips the name/id read probe, so a create-scoped key that cannot read `/databases` can load into a database it just created.
 
 ### `QueryResult`
 
@@ -79,7 +83,6 @@ Adapters should import from `hotdata_framework` and treat this surface as the st
 
 - `default_api_key()` reads `HOTDATA_API_KEY`.
 - `default_host()` reads `HOTDATA_API_URL` (default: `https://api.hotdata.dev`) and normalizes it.
-- `default_session_id()` reads `HOTDATA_SANDBOX`.
 - `explicit_workspace_id()` reads `HOTDATA_WORKSPACE` (workspace public id).
 - `pick_workspace()` prefers explicit env workspace, then active workspace, then first workspace.
 - `resolve_workspace_selection()` is the canonical workspace selection algorithm. It returns `WorkspaceSelection` with selected workspace id, selection source, and discovered workspaces when auto-selected.

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/PKG-INFO

@@ -1,7 +1,7 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: hotdata-framework
-Version: 0.10.0
-Summary: Python framework for building Hotdata integrations: workspace/session runtime, query execution, and managed databases
+Version: 0.12.0
+Summary: Python framework for building Hotdata integrations: workspace runtime, query execution, and managed databases
 Project-URL: Homepage, https://www.hotdata.dev
 Project-URL: Documentation, https://www.hotdata.dev/docs
 Project-URL: Repository, https://github.com/hotdata-dev/sdk-python-framework
@@ -21,7 +21,7 @@ Classifier: Topic :: Software Development :: Libraries :: Application Frameworks
 Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Classifier: Typing :: Typed
 Requires-Python: >=3.10
-Requires-Dist: hotdata>=0.8.0
+Requires-Dist: hotdata<0.10,>=0.9.0
 Requires-Dist: pandas>=2.0
 Requires-Dist: pyarrow>=14.0
 Description-Content-Type: text/markdown
@@ -30,16 +30,15 @@ Description-Content-Type: text/markdown
 
 **A Python framework for building Hotdata integrations.**
 
-Shared runtime primitives for Hotdata integrations: workspace/session semantics, execution context, query state, run history, and replayable result handles. Framework packages (Marimo, Jupyter, Streamlit, LangGraph) depend on this package.
+Shared runtime primitives for Hotdata integrations: workspace semantics, execution context, query state, run history, and replayable result handles. Framework packages (Marimo, Jupyter, Streamlit, LangGraph) depend on this package.
 
 Runtime boundary and guarantees are defined in `CONTRACT.md`.
 
 ## Features
 
-- **Environment-driven client setup** — create clients from `HOTDATA_API_KEY`, optional `HOTDATA_API_URL`, `HOTDATA_WORKSPACE`, and `HOTDATA_SANDBOX`.
+- **Environment-driven client setup** — create clients from `HOTDATA_API_KEY`, optional `HOTDATA_API_URL`, and `HOTDATA_WORKSPACE`.
 - **Workspace resolution** — choose an explicit workspace from env, otherwise discover workspaces and select the active workspace or first available workspace.
-- **Sandbox/session propagation** — pass sandbox session context through the SDK via `X-Session-Id`.
-- **HTTP resilience** — configure SDK retries for transient connection failures and retry SQL execution on stale pooled sockets.
+- **HTTP resilience** — retry SQL execution on stale pooled sockets. Transport-level retries are the SDK's own default, which this package leaves in place so a non-idempotent request is never replayed on a response status.
 - **SQL execution helper** — run SQL through `POST /v1/query`, poll async query runs when needed, and return a `QueryResult`.
 - **Result utilities** — convert query results to records, pandas DataFrames, or metadata dictionaries for adapter display layers.
 - **History helpers** — list recent results and query run history with normalized dataclasses.

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/README.md

@@ -2,16 +2,15 @@
 
 **A Python framework for building Hotdata integrations.**
 
-Shared runtime primitives for Hotdata integrations: workspace/session semantics, execution context, query state, run history, and replayable result handles. Framework packages (Marimo, Jupyter, Streamlit, LangGraph) depend on this package.
+Shared runtime primitives for Hotdata integrations: workspace semantics, execution context, query state, run history, and replayable result handles. Framework packages (Marimo, Jupyter, Streamlit, LangGraph) depend on this package.
 
 Runtime boundary and guarantees are defined in `CONTRACT.md`.
 
 ## Features
 
-- **Environment-driven client setup** — create clients from `HOTDATA_API_KEY`, optional `HOTDATA_API_URL`, `HOTDATA_WORKSPACE`, and `HOTDATA_SANDBOX`.
+- **Environment-driven client setup** — create clients from `HOTDATA_API_KEY`, optional `HOTDATA_API_URL`, and `HOTDATA_WORKSPACE`.
 - **Workspace resolution** — choose an explicit workspace from env, otherwise discover workspaces and select the active workspace or first available workspace.
-- **Sandbox/session propagation** — pass sandbox session context through the SDK via `X-Session-Id`.
-- **HTTP resilience** — configure SDK retries for transient connection failures and retry SQL execution on stale pooled sockets.
+- **HTTP resilience** — retry SQL execution on stale pooled sockets. Transport-level retries are the SDK's own default, which this package leaves in place so a non-idempotent request is never replayed on a response status.
 - **SQL execution helper** — run SQL through `POST /v1/query`, poll async query runs when needed, and return a `QueryResult`.
 - **Result utilities** — convert query results to records, pandas DataFrames, or metadata dictionaries for adapter display layers.
 - **History helpers** — list recent results and query run history with normalized dataclasses.

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/RELEASING.md

@@ -34,6 +34,27 @@ Pushing a `vX.Y.Z` tag triggers two workflows:
 | `publish.yml` | Build wheel/sdist and publish to PyPI |
 | `release.yml` | Create the GitHub Release with notes from `CHANGELOG.md` |
 
+## If a release workflow fails
+
+Both workflows also accept a manual re-run against an existing tag, so a failure
+unrelated to the code — a stale action pin, a PyPI outage — does not require
+deleting the tag or burning a version number:
+
+```bash
+gh workflow run "Publish to PyPI" --ref main -f tag=vX.Y.Z
+gh workflow run "GitHub Release"  --ref main -f tag=vX.Y.Z
+```
+
+`--ref main` selects the workflow *definition*, so a fix to the workflow file
+itself is picked up; everything it runs — including `scripts/extract-changelog.py`
+— still comes from the tag, since that is what is being built and released. The
+two refs serve different purposes, which is why they can differ.
+
+A version is only spent once PyPI has accepted an upload. If the publish failed
+before that, the same version can still be published — check with
+`curl -s -o /dev/null -w '%{http_code}' https://pypi.org/pypi/<pkg>/<version>/json`
+returning 404.
+
 ## Enforcement
 
 - **PR check** (`check-release.yml`): if `pyproject.toml` version changes, `CHANGELOG.md` must contain a matching `## [X.Y.Z]` section.

{hotdata_framework-0.10.0 → hotdata_framework-0.12.0}/hotdata_framework/__init__.py

@@ -2,6 +2,9 @@
 
 from importlib.metadata import PackageNotFoundError, version
 
+from hotdata.models.table_partition_key import TablePartitionKey
+from hotdata.models.table_sort_key import TableSortKey
+
 from hotdata_framework.client import (
     HotdataClient,
     ResultSummary,
@@ -14,13 +17,13 @@ from hotdata_framework.databases import (
     LoadManagedTableResult,
     ManagedDatabase,
     ManagedTable,
+    TableLayout,
     is_parquet_path,
 )
 from hotdata_framework.env import (
     WorkspaceSelection,
     default_api_key,
     default_host,
-    default_session_id,
     explicit_workspace_id,
     list_workspaces,
     normalize_host,
@@ -56,12 +59,14 @@ __all__ = [
     "QueryResult",
     "ResultSummary",
     "RunHistoryItem",
+    "TableLayout",
+    "TablePartitionKey",
+    "TableSortKey",
     "WorkspaceSelection",
     "__version__",
     "classify_sdk_error",
     "default_api_key",
     "default_host",
-    "default_session_id",
     "explicit_workspace_id",
     "from_env",
     "is_parquet_path",