mengw15 opened a new issue, #7753: URL: https://github.com/apache/texera/issues/7753
### Task Summary Part of #6870, follow-up to #6932. `WarehouseResource` derives the Lakekeeper warehouse 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 — which freezes the user-facing name at creation time. Renaming would have to rename the Lakekeeper warehouse and rewrite every stored URI, so today a warehouse can never be renamed. Computing units rename freely precisely because their name is pure display metadata: `cuid` is the identity everywhere else. Decouple the two, the way display names and stable identifiers are separated in catalog systems generally: - **Generate the catalog name from a stable id**: `user-<uid>-<8 random hex>`, chosen at creation. The creation flow is unchanged — the suffix exists before the Lakekeeper create, so the order (Lakekeeper first, then the DB row, with the existing compensating delete) and the schema stay as they are. A suffix collision surfaces as Lakekeeper's own name-conflict error and retries with a fresh suffix. (Deriving from `whid` instead would need the DB row before the Lakekeeper create — an order flip plus a nullable column — for no benefit.) - **`name` stays the per-user-unique display name** in `user_warehouse`, now free to change: a rename endpoint mirroring computing-unit rename becomes a straightforward follow-up (not part of this task). Nothing downstream cares: stored URIs embed the catalog name opaquely, and after #6933 the frontend no longer displays it anywhere — it shows `name`. The S3 layout becomes `user-<uid>-<hex>/` instead of `user-<uid>-<name>/`. Worth doing while the flag is off everywhere: no deployment holds warehouses yet, so the naming scheme can change with zero migration. Once real data exists under name-derived prefixes, this becomes a migration project. ### Task Type - [x] Other (feature implementation) -- 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]
