Skip to content

Commit 4a6762d

Browse files
authored
fix(databases): surface the id change when load recreates a managed database (#173)
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. Co-authored-by: Eddie A Tejeda <669988+eddietejeda@users.noreply.github.com>
1 parent 6227a9b commit 4a6762d

2 files changed

Lines changed: 25 additions & 0 deletions

File tree

‎skills/hotdata/references/WORKFLOWS.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -106,6 +106,8 @@ End-to-end checklists. Use the linked sections for command detail and guardrails
106106
hotdata databases load --catalog sales --table customers --url https://example.com/customers.parquet
107107
```
108108

109+
> Auto-declaring a *new* table recreates the database (no add-table API), which **changes its `id`**. Always reference a managed database by its **catalog** (stable), not the `id` returned by `databases create` — that id goes stale after the next `load` of an undeclared table. Declare tables up front (`databases create --table orders --table customers`) to avoid the recreate.
110+
109111
3. Confirm and query:
110112

111113
```bash

‎src/databases.rs‎

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1013,6 +1013,29 @@ pub fn tables_load(
10131013
}
10141014
};
10151015
let _ = crate::config::save_current_database("default", workspace_id, &new_db.id);
1016+
// Managed databases have no add-table endpoint, so declaring a new table
1017+
// is a delete + recreate — which mints a NEW database id. Surface that
1018+
// explicitly: the id printed by `databases create` is now stale, and
1019+
// id-based automation (e.g. `databases delete <create-time-id>`) would
1020+
// otherwise fail with "no database with id". Reference by catalog instead.
1021+
{
1022+
use crossterm::style::Stylize;
1023+
let catalog = db
1024+
.default_catalog
1025+
.as_deref()
1026+
.or(db.name.as_deref())
1027+
.unwrap_or(&db.id);
1028+
eprintln!(
1029+
"{}",
1030+
format!(
1031+
"note: table '{table}' was not declared — recreated database '{catalog}' to add it \
1032+
(id {} → {}). Managed databases are recreated when a new table is loaded; \
1033+
reference them by catalog ('{catalog}'), not the create-time id.",
1034+
db.id, new_db.id
1035+
)
1036+
.yellow()
1037+
);
1038+
}
10161039
let new_path = managed_table_load_path(&new_db.default_connection_id, schema, table);
10171040
let spinner = crate::util::spinner("Loading table...");
10181041
let result = api.post_raw(&new_path, &body).unwrap_or_else(|e| {

0 commit comments

Comments
 (0)