mengw15 opened a new pull request, #7754: URL: https://github.com/apache/texera/pull/7754
### What changes were proposed in this PR? `WarehouseResource` derived the Lakekeeper catalog name from the user-facing name: `user-<uid>-<name>`. That one string is simultaneously the Lakekeeper warehouse identifier, the REST catalog URL prefix, the S3 key prefix, and a component of every result URI stored by executions that wrote into the warehouse — so the display name was frozen at creation and a warehouse could never be renamed. Computing units rename freely precisely because their name is pure display metadata; `cuid` is the identity everywhere else. - **Derive the catalog name from the row id**: `user-<uid>-<whid>`. The id is drawn from the table's own sequence **before** the Lakekeeper call, so the creation order is unchanged — Lakekeeper first, DB row after, with the existing compensating delete — and no schema or nullability change is needed. The sequence is resolved through `pg_get_serial_sequence` rather than named literally, because the generated sequence name is not a stable contract (the jOOQ output already carries both `user_warehouse_whid_seq` and `..._seq1` from a re-created table). - **`name` stays the per-user-unique display name**, now free to change; a rename endpoint mirroring computing-unit rename becomes a straightforward follow-up. - **Rename the column**: `user_warehouse.warehouse_name` → `lakekeeper_warehouse_name`, matching its sibling `lakekeeper_warehouse_id`. The wire DTO keeps `warehouseName`. **Deviation from the issue, and why.** The issue proposed `user-<uid>-<8 random hex>`, on the reasoning that deriving from `whid` "would need the DB row before the Lakekeeper create — an order flip plus a nullable column". Taking the id from the sequence up front avoids both, so that cost does not apply. Doing so also removes the collision-retry path the random suffix required: a 32-bit suffix collides often enough to need one, and that retry would have to recognise Lakekeeper's name-conflict error — the same brittle response-parsing #7742 just had to harden. A sequence-derived name cannot collide, and `user-7-42` points straight at `whid = 42` when tracing storage back to a row. **On "zero migration".** No *data* migration is needed — the table is empty in every deployment while the flag is off — but the column rename still needs a schema migration (`sql/updates/38.sql`): `texera_ddl.sql` is `CREATE TABLE IF NOT EXISTS`, so an existing database keeps the old column, and jOOQ generates its code from the live database. Without the migration, existing databases would generate `WAREHOUSE_NAME` and fail to compile against this change. ### Any related issues, documentation, discussions? Closes #7753. Part of #6870, follow-up to #6932. Worth settling while the flag is off everywhere: once real data exists under name-derived prefixes, this becomes a migration project. ### How was this PR tested? - `WarehouseResourceSpec` now asserts the catalog name equals `user-<uid>-<whid>` and **does not contain the display name**, pinning the decoupling itself. - New case: deleting a warehouse and recreating it with the same display name mints a **different** catalog name — a reused name would let a new warehouse inherit an old one's storage path. - The two compensation cases previously created their conflict by pre-claiming `user-<uid>-<name>`, which this change makes unreachable. They now draw an id from the sequence, set it explicitly on the squatter row (so storing it consumes nothing further), and squat on the next one — so they still exercise the `UNIQUE` conflict, and additionally pin the "catalog name = uid + sequence id" rule. - `WarehouseResourceSpec` + `WorkflowServiceWarehouseSpec` + `ExecutionsMetadataPersistServiceSpec` run locally: **26/26 passed** against a database migrated with `sql/updates/38.sql` and jOOQ regenerated from it; `WorkflowExecutionService/scalafmtCheck` (main + Test) passes. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-4-8) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
