Context
An external power-user (on a project with the storage-branches feature flag confirmed ON) is using kbagent storage swap-tables as part of the documented "typify" workflow (rebuild a typeless STRING(16M) table into native types via CTAS in a dev branch, then swap the typed sibling into the original table ID).
They've hit a conceptual gap about how the swap interacts with merging the dev branch back to production, and since @zajca designed both storage-branches and the table-swap operation, we'd like to confirm the intended design before answering them.
The question
On a storage-branches project:
- A table is swapped inside a dev branch (
POST /v2/storage/branch/{id}/tables/{id}/swap) so that in.c-foo.data now carries the typed schema and in.c-foo.data_typed holds the old typeless rows.
- When the user merges that dev branch, does the swapped (typed) physical table propagate to production storage? Or does branch merge only carry configurations, leaving production storage on the original typeless table?
Our workflow docs (typify-table-workflow.md, Phase 8) currently assert "the typed schema lands in production (branched-storage propagation); the sibling carrying the typeless rows survives the merge" — but this is documented, not test-verified (our E2E only covers the swap inside the branch, not merge propagation). We don't want to give the user wrong guidance.
Why it matters (user's concern)
The user's worry is a dilemma:
- If the swap reaches production immediately → it breaks prod (downstream transformations aren't ready for typed input yet).
- If it never reaches production → the typed table is "stuck forever in the dev branch" and merge changes nothing in storage, making swap-tables useless to them.
Our reading is that neither is true on storage-branches: the swap is branch-scoped (prod keeps running on the typeless original), and merge is what promotes it — but we need @zajca to confirm the merge-propagation behavior for a physical table swap (as opposed to a config change).
Secondary, related request
The same user wants to DROP columns safely in a dev branch (lineage-driven column removal). On a copy-on-write storage-branches project, a branch reads prod tables transparently until first write — so to mutate a table's schema in the branch they first need a branch-local materialization of the prod table. kbagent today can create an empty branch table (create-table --branch) but cannot clone an existing prod table into the branch. Worth a dedicated command (e.g. storage clone-table --branch)? (Happy to split this into its own issue if preferred.)
cc @zajca
Context
An external power-user (on a project with the
storage-branchesfeature flag confirmed ON) is usingkbagent storage swap-tablesas part of the documented "typify" workflow (rebuild a typelessSTRING(16M)table into native types via CTAS in a dev branch, then swap the typed sibling into the original table ID).They've hit a conceptual gap about how the swap interacts with merging the dev branch back to production, and since @zajca designed both storage-branches and the table-swap operation, we'd like to confirm the intended design before answering them.
The question
On a
storage-branchesproject:POST /v2/storage/branch/{id}/tables/{id}/swap) so thatin.c-foo.datanow carries the typed schema andin.c-foo.data_typedholds the old typeless rows.Our workflow docs (
typify-table-workflow.md, Phase 8) currently assert "the typed schema lands in production (branched-storage propagation); the sibling carrying the typeless rows survives the merge" — but this is documented, not test-verified (our E2E only covers the swap inside the branch, not merge propagation). We don't want to give the user wrong guidance.Why it matters (user's concern)
The user's worry is a dilemma:
Our reading is that neither is true on
storage-branches: the swap is branch-scoped (prod keeps running on the typeless original), and merge is what promotes it — but we need @zajca to confirm the merge-propagation behavior for a physical table swap (as opposed to a config change).Secondary, related request
The same user wants to DROP columns safely in a dev branch (lineage-driven column removal). On a copy-on-write
storage-branchesproject, a branch reads prod tables transparently until first write — so to mutate a table's schema in the branch they first need a branch-local materialization of the prod table. kbagent today can create an empty branch table (create-table --branch) but cannot clone an existing prod table into the branch. Worth a dedicated command (e.g.storage clone-table --branch)? (Happy to split this into its own issue if preferred.)cc @zajca