[shefeek-jinnah]

What

Widens the hotdata SDK pin >=0.7,<0.8 → >=0.7,<0.9 so this backend can run alongside hotdata 0.8.0 (the per-load-key release). Releases 0.3.2.

Why it's safe (no code change)

hotdata 0.8.0 is additive — it adds a key field on the load-request model and a fork endpoint; nothing is removed or renamed. Verified every hotdata symbol this backend imports (ApiClient, Configuration, DatabasesApi, ApiException, QueryRequest, CreateDatabaseRequest, DatabaseDefaultSchemaDecl, DatabaseDefaultTableDecl, LoadManagedTableRequest, AsyncQueryResponse) resolves unchanged against 0.8.0. Mirrors the 0.3.1 cap bump.

Unblocks

hotdata-dlt-destination's [ibis] extra pins hotdata-ibis>=0.3.1,<0.4 and now requires hotdata 0.8.0; its --all-extras lock can't resolve until this ships (the connector's existing pin auto-picks 0.3.2).

Tests

No src change. uv.lock regenerated (hotdata → 0.8.0). CI (uv sync --all-groups + ruff + pytest) unaffected.

[claude]

Clean dependency cap bump. Verified all imported hotdata symbols in src/ibis_hotdata/http.py match those listed in the PR description, version is consistent across pyproject.toml, uv.lock, and CHANGELOG.md, and __version__ is sourced from package metadata (no manual bump needed).

[rohan-hotdata]

Reviewed this against a live check, not just the description — a couple of findings:

CI is actually failing (blocking)

Test fails on all 5 Python versions on this PR. I reproduced locally: installed hotdata==0.8.0 over main and ran the offline suite — 11 failed, all the same error:

pydantic_core._pydantic_core.ValidationError: 1 validation error for CreateDatabaseResponse
default_schema
  Input should be a valid string [type=string_type, input_value=None, input_type=NoneType]

Root cause: SDK 0.8.0 adds default_schema: StrictStr as a required, non-nullable field to three response models — CreateDatabaseResponse, DatabaseDetailResponse, DatabaseSummary — deserialized inside the hotdata package itself, before any ibis_hotdata code runs. The PR's "every symbol this backend imports resolves unchanged" check covered imports/method signatures but not response-payload shape, so this slipped through. This repo's test mocks (e.g. managed_database_detail_response() in tests/test_hotdata_backend.py:58-66, and the canned dict at tests/test_hotdata_http.py:294) don't include default_schema, so pydantic rejects them on parse.

The fix is small — add "default_schema": <value> to the mocked JSON bodies for create_database/get_database/list_databases responses in tests/test_hotdata_backend.py and tests/test_hotdata_http.py — but it is a real code change needed before merge, not "no code changes."

Good news: not a real backward-compat break

I forced hotdata==0.8.0 into the venv and ran examples/05_roundtrip_demo.py live against hosted Hotdata (create → write → read → drop). It passed end-to-end — the real server already emits default_schema on every response. So this is purely stale local test fixtures, not a production risk. Once the mocks are updated this should be safe to merge.

Minor nit (non-blocking)

This PR bundles the dependency bump with the version bump + CHANGELOG dating in one PR. The convention we've used on the last couple of releases (see #35 / #37) is to keep those separate — a fix/chore PR, then a dedicated release.sh prepare PR — per RELEASING.md. Not a blocker for a change this small, but flagging for consistency going forward.

[claude]

Verified: version/pin/lock consistent (0.3.1→0.3.2, hotdata pin <0.8→<0.9, lock at 0.8.0), CHANGELOG accurate, and all five database-response fixtures updated with the now-required default_schema field. No source impact.

[rohan-hotdata]

Verified the fix independently (not just relying on green CI):

• Diffed the follow-up commit: `default_schema` was added to all four mocked response sites that needed it — `managed_databases_response()`, `managed_database_detail_response()` (both in tests/test_hotdata_backend.py), the two inline dicts around line ~565/591 in the same file, and the mock in tests/test_hotdata_http.py:294 — exactly the call sites behind the 11 failures I found earlier.
• Checked out the PR branch locally and ran the full offline suite with its own lockfile (hotdata==0.8.0): 101 passed.
• Re-ran examples/05_roundtrip_demo.py live against hosted Hotdata on this branch (create → write → read via .execute()/.to_pyarrow() → drop): passes end-to-end.

CI is green across all 5 Python versions too. This looks good to merge from my side — nothing further blocking. The bundled-release-PR nit from my earlier comment still stands but isn't a blocker for a change this size.