Skip to content

fix(databases): surface the id change when load recreates a managed database#173

Merged
eddietejeda merged 1 commit into
mainfrom
fix/databases-load-recreate-id-notice
Jun 20, 2026
Merged

fix(databases): surface the id change when load recreates a managed database#173
eddietejeda merged 1 commit into
mainfrom
fix/databases-load-recreate-id-notice

Conversation

@eddietejeda

Copy link
Copy Markdown
Contributor

Summary

Loading an undeclared table into a managed database triggers an auto-declare path that delete + recreates the database (managed DBs have no add-table endpoint) — which mints a new database id. This was silent unless existing tables had synced data, so:

  • the id printed by databases create goes stale after the next load of a new table, and
  • databases delete <create-time-id> then fails with "no database with id".

I hit this directly while testing: databases create --catalog X printed one id, but after databases load the database was listed under a different id, and delete-by-printed-id failed.

Root cause

databases create is correct — its returned id matches databases list immediately (verified). The id only changes inside tables_load's recreate path (src/databases.rs), and that change was never surfaced when there was no synced data to warn about.

Fix

  • Emit a clear note when load recreates the database, showing id <old> → <new> and pointing users to reference managed databases by catalog (stable), not the create-time id.
  • Document the same in the managed-database workflow (references/WORKFLOWS.md): auto-declaring a new table recreates the DB and changes its id; reference by catalog, or declare tables up front with databases create --table ….

No server change needed; this is a transparency fix for an inherent consequence of the recreate workaround.

Verification (production)

$ hotdata databases create --catalog probe_notice      # id A
$ hotdata databases load --catalog probe_notice --table t --file probe.parquet
note: table 't' was not declared — recreated database 'probe_notice' to add it
(id dbidybn82eo… → dbidsqfb9xo…). … reference them by catalog ('probe_notice'),
not the create-time id.
$ hotdata databases delete probe_notice                 # delete by catalog works
Database deleted.

cargo build/clippy/fmt clean; databases test suite green (23 passed).

… database

Loading an undeclared table into a managed database triggers an
auto-declare path that delete+recreates the database (managed DBs have no
add-table endpoint), which mints a NEW database id. This was silent unless
existing tables had synced data — so the id printed by `databases create`
would go stale after the next `load`, and `databases delete <create-id>`
failed with "no database with id".

Emit a clear note on the recreate (old id -> new id) and point users to
reference managed databases by catalog (stable) rather than the
create-time id. Document the same in the managed-database workflow.

`databases create` itself is correct — the printed id matches `databases
list` immediately; only `load`'s recreate changed it.

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Focused transparency fix. The recreate-path note is correctly gated on the "not declared" branch, the id old→new values and catalog fallback match the adjacent synced-data block, and the style follows existing conventions. LGTM.

@codecov

codecov Bot commented Jun 20, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/databases.rs 0.00% 8 Missing ⚠️

📢 Thoughts on this report? Let us know!

@eddietejeda eddietejeda merged commit 4a6762d into main Jun 20, 2026
14 checks passed
@eddietejeda eddietejeda deleted the fix/databases-load-recreate-id-notice branch June 20, 2026 01:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant