Repository navigation
Conversation
Contributor
|
Commit: Regression test reportSelected 20 changed tests (limit=20, 32 not selected) 45 tests: regression=43 unreleased=0 coverage=2 failing=0
TestAccept/bundle/resources/catalogs/rename/DMS=/READPLAN=: branch ✅ | main (37cd1d9) ❌ | latest (v1.25.0) ❌main (37cd1d9): latest (v1.25.0): TestAccept/bundle/resources/catalogs/rename/DMS=/READPLAN=1: branch ✅ | main (37cd1d9) ❌ | latest (v1.25.0) ❌main (37cd1d9): latest (v1.25.0): TestAccept/bundle/resources/catalogs/rename/DMS=true/READPLAN=: branch ✅ | main (37cd1d9) ❌ | latest (v1.25.0) ❌main (37cd1d9): latest (v1.25.0): 40 more failure details omitted, see the full report in the run. |
denik
force-pushed
the
denik/schemas-remove
branch
from
November 4, 2026 13:15
c643054 to
3aabe1b
Compare
Collaborator
✅ Integration test reportCommit: 8e778fa
Top 6 slowest tests (at least 2 minutes):
|
denik
force-pushed
the
denik/schemas-remove
branch
4 times, most recently
from
November 4, 2026 15:00
5f6e047 to
0d42d75
Compare
denik
force-pushed
the
denik/schemas-remove
branch
2 times, most recently
from
November 4, 2026 16:43
3678e96 to
891fceb
Compare
denik
force-pushed
the
denik/schemas-remove
branch
from
November 4, 2026 16:50
891fceb to
fe7fb69
Compare
denik
marked this pull request as ready for review
November 5, 2026 12:59
denik
force-pushed
the
denik/schemas-remove
branch
from
November 5, 2026 13:09
a4a9475 to
6845544
Compare
andrewnester
approved these changes
Nov 5, 2026
denik
force-pushed
the
denik/schemas-remove
branch
from
November 5, 2026 13:57
4f7fd4e to
27ceb82
Compare
denik
changed the title
pietern
reviewed
Nov 5, 2026
| return fullName, nil, nil | ||
| } | ||
|
|
||
| response, err := r.client.Schemas.Update(ctx, makeUpdateSchema(fullName, newName, config)) |
Contributor
There was a problem hiding this comment.
IIRC including other fields during a rename caused issues.
Also; what happens if we rename to something that UC considers equivalent?
E.g. case change (via EqualFold)?
Contributor
Author
There was a problem hiding this comment.
schemas/rename_with_comment covers rename + update and schemas/rename_case_only covers case change. Both work on cloud. In case of case_only change there is one avoidable PATCH but it's not harmful (and makes DABs more independent of backend folding rules).
…nal IDs there An update_id whose changes only follow a parent's rename (or a move the plan found) is marked state_only. For a resource with IDFromState, apply records it under the new ID without calling DoUpdateWithID; it is left out of the textual plan and the applied lines, and counted as unchanged. The internal ID is declared in config as internal_id_field. The framework records it from the remote state on every save, skips its changes in the plan and reads it in findMoved, replacing the InternalID method, the YAML ignore rules and the VolumeId/SchemaId assignments in the adapters. Co-authored-by: Isaac <no-reply@databricks.com>
A schema or catalog renamed with its comment changed sends both in one PATCH and both land. A case-only rename of a schema or volume is accepted by UC, which keeps the lowercase name, so the deploy succeeds and the next plan is a no-op. The test server now lowercases a renamed volume, like UC. Co-authored-by: Isaac <no-reply@databricks.com>
…hain Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
…leReason Co-authored-by: Isaac <no-reply@databricks.com>
…ting on main) Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
…; record volume_id in empty-resource-id The volume's created_at/updated_at made rename_interrupted flaky ([UNIX_TIME_MILLIS] vs [UNIX_TIME_MILLIS][0] depending on timing). Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Jan N Rose <janniklas.rose@gmail.com>
The recreate deletes the volume at its recorded path after the schema's rename moved it, so the moved volume is left behind. Co-authored-by: Isaac <no-reply@databricks.com>
A parent renamed in the same plan moves the resource before its recreate runs. The recreate now deletes it at the ID the rename gives it, after the rename. The parent comes from the state's depends_on, since the config may no longer reference it. Co-authored-by: Isaac <no-reply@databricks.com>
The plan's state_only re-keys, found IDs and added depends_on must survive serialization. Co-authored-by: Isaac <no-reply@databricks.com>
denik
force-pushed
the
denik/schemas-remove
branch
from
November 10, 2026 16:20
947cc9d to
da3786a
Compare
Numbered UUIDs from main (#7021); restores the volume_id skip in change-name and the recorded schema_id in user_agent/simple, which the rebase dropped. Co-authored-by: Isaac <no-reply@databricks.com>
… case-insensitive volume lookups On AWS the re-keyed ID keeps the config's casing (main.s.MyVolume) and UC still reads the volume at it, so the next plan is a no-op. The test server now looks a volume's full name up case-insensitively too, instead of planning a create. Co-authored-by: Isaac <no-reply@databricks.com>
Without IDFromState the update_id would reach DoUpdateWithID with the stale ID. Co-authored-by: Isaac <no-reply@databricks.com>
…ew B5) Co-authored-by: Isaac <no-reply@databricks.com>
…ad (review B6) Co-authored-by: Isaac <no-reply@databricks.com>
…view B7) Co-authored-by: Isaac <no-reply@databricks.com>
…w B8) Co-authored-by: Isaac <no-reply@databricks.com>
…om four goldens Co-authored-by: Isaac <no-reply@databricks.com>
… rename (review A3, Badness); testserver: reject a taken schema name Recorded on AWS: the schema's create fails with SCHEMA_ALREADY_EXISTS. The test server now rejects it the same way instead of creating it again. Co-authored-by: Isaac <no-reply@databricks.com>
The test server now rejects a taken schema name, as UC does. Co-authored-by: Isaac <no-reply@databricks.com>
… A3) A state recorded without schema_id/volume_id (by an older CLI, or by bind) never got them, since a skip writes no state, so the plan could not follow an out-of-band rename. An otherwise unchanged resource whose state lacks the ID is now planned as a state-only update that records it from the remote state. Co-authored-by: Isaac <no-reply@databricks.com>
…y (review A3) The terraform state has no volume_id, and the migrated state would otherwise get the IDs from a state-only update in the next plan. The migration's plan check already read every resource, so record them from there. Co-authored-by: Isaac <no-reply@databricks.com>
The provider records UC's schema_id on databricks_schema. databricks_volume has no volume_id, so a volume migrated this way has none. Co-authored-by: Isaac <no-reply@databricks.com>
… requests The fixture was captured with the init script, so replaying it after the init created the source schema twice, which the test server now rejects as UC does. Co-authored-by: Isaac <no-reply@databricks.com>
idelafuente-oc
pushed a commit
to idelafuente-oc/cli
that referenced
this pull request
Nov 11, 2026
## Changes Grants are keyed by their parent's full name (`volume/main.s.vol`). When the parent got a new ID, the grants were applied under the new name, but their state kept the old ID. This happens on a rename (catalogs, volumes) or a recreate under a new name (schemas). The next `bundle plan` then proposed the grants again. On UC the old name 404s, so the plan shows `create ...grants` once; on the test server the plan shows `update ...grants` forever. `full_name` is now an `updatable_id_fields` entry for every grants type, and `DoUpdateWithID` records the new ID. This follows `secret_scopes.permissions.yml`, which solves the same problem for secret scope ACLs. The rule lives in a single `configs/grants.yml`: a config file named after a sub-resource now applies to that sub-resource of every parent (`catalogs.grants`, `schemas.grants`, ...). Needed before databricks#7343 (schema rename), so that renamed schemas keep their grants in sync. ## Tests New acceptance tests, `Cloud = true`, passing locally and on AWS: - `grants/volume_change_name`: volume rename (`update_id`). - `grants/schemas/change_name`: schema name change (a recreate today). The first commit adds them with the pre-fix goldens; the second commit shows the fix flipping them to a no-op plan. This pull request and its description were written by Isaac. --------- Co-authored-by: Isaac <no-reply@databricks.com>
idelafuente-oc
pushed a commit
to idelafuente-oc/cli
that referenced
this pull request
Nov 11, 2026
…names (databricks#7408) ## Changes Make the test server behave like Unity Catalog where the UC rename PRs depend on it: - A renamed catalog moves its schemas, volumes, registered models and secrets. A renamed schema moves its volumes, registered models and secrets. - A forced catalog or schema delete also deletes what is in it. - Creating a catalog under a taken name fails with `CATALOG_ALREADY_EXISTS`. - A renamed schema or volume gets a lowercased name. A renamed registered model updates its `full_name` and keeps its versions, and setting `name` and `new_name` in one update is rejected. The `schema-catalog-change` and `registered-model-catalog-change` migrate scripts created a catalog that their captured replay creates again; the fake now rejects that, so the scripts no longer create it. ## Tests New `acceptance/cmd/workspace/uc-renames` (Cloud = true) checks each behavior with plain CLI calls. It passes locally and on AWS, GCP and Azure. Next: databricks#7343 (schema rename) stacks on this PR, followed by databricks#7379 and databricks#7381. This pull request and its description were written by Isaac. --------- Co-authored-by: Isaac <no-reply@databricks.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
Changing a schema's
namenow renames it in place (PATCH new_name) instead of deleting and recreating it, so the schema and its contents survive.UC moves the children of a renamed catalog or schema along with it. A volume in a renamed schema, or a schema in a renamed catalog (
schema_name/catalog_name: ${resources.<parent>.name}), used to be planned as a recreate. Its create then failed withRESOURCE_ALREADY_EXISTSon every deploy, because the recreate had already dropped it from state. The planner now re-keys such children (update_id, reasonparent_renamed) under their new parents. Catalog rename was already supported and had the same latent bug for child schemas.A child whose only change is following its parent is planned
state_only: the framework saves it under the ID the adapter's new optionalIDFromStategives it, with no request. Such entries are left out of the text plan and counted as unchanged. A child with its own changes too goes throughDoUpdateWithID, which addresses it at its new path.A resource can also be missing from its recorded ID with no rename in the plan: a deploy stopped after renaming the parent, or the resource or its parent was renamed out of band. When the read at the recorded ID finds nothing, the plan reads at the
IDFromStateID. It takes what it finds only if its internal ID matches the one in the state. The newinternal_id_fieldlifecycle setting names it (schema_id,volume_id); the framework records it from the remote state on every save, and the plan skips it (reasoninternal_id). A different object under that name is planned as a create, which UC rejects, so it is never adopted. The plan entry'sidfield (declared, but never set until now) records where the resource was found, and apply addresses it there. Catalogs have no internal ID and are not looked for yet. With the new state fields,apitypes.generated.ymlnow maps schemas and volumes toSchemaInfo/VolumeInfo, as registered models already map to their Info type.A resource recreated in the same deploy as its parent's rename is now deleted where the rename moved it. The parent's rename runs first and moves the resource, so the plan points the recreate's delete at the re-keyed ID (the entry's
id) and orders it after the parent. The parent comes from the state'sdepends_on, because the config may now reference another one. Before, the delete went to the old path, got a 404, and the moved volume was left behind untracked.The test server changes this relies on are in #7408 (merged). With #7345 and #7361 (merged), which re-key grants and permissions when their parent's ID changes, a renamed schema keeps those in sync too. Registered models and UC secrets follow parent renames in #7379 and #7381.
Tests
Cloud = true, passing locally and on AWS, GCP and Azure:schemas/rename,schemas/rename_with_volume,catalogs/rename(catalog → schema → volume).schemas/rename_then_change: after a parent rename, a volume update, rename and recreate all reach its new path, also after a second rename and a rename back.volumes/rename_catalog_and_schema: the catalog and the schema are renamed in one deploy, so the volume follows two parent renames at once. It gets no request and keeps itsvolume_id.schemas/rename_with_volume_ref: a job reading the volume'sfull_name,idandvolume_idgets the right values after the rename.schemas/rename_with_comment,catalogs/rename_with_comment(rename and comment change go in one PATCH) andschemas/rename_case_only,volumes/rename_case_only(UC accepts the update and keeps the lowercase name; the redeploy is a no-op).schemas/rename_interrupted(local only; uses the test server's kill hook): the CLI is killed after the schema's rename is saved and before the volume's re-key. The next deploy finds the volume at its new path byvolume_id. Without the fix it planned a create.schemas/recreate_interrupted(local only): the same kill during a recreate of the schema under a new name. The volume went with the old schema, so the next deploy creates a new one.Cloud = true, config renamed to match:volumes/rename_out_of_bandandschemas/rename_out_of_band(found byvolume_id/schema_id, deploy sends no requests);catalogs/rename_out_of_bandandcatalogs/rename_all_out_of_band(schema and volume found; the catalog's create fails withCATALOG_ALREADY_EXISTS, as on main, markedBadness; Find a catalog renamed outside the bundle by its id #7418 fixes it).volumes/move_from_renamed_schema(Cloud = true) andvolumes/recreate_in_renamed_schema(local only: an external volume needs an external location): a volume recreated while its schema is renamed, by moving it to another schema or changing its type. The old volume is deleted where the rename moved it.Cloud = true:volumes/recreate_out_of_bandandschemas/recreate_out_of_band. An object is found under the new name but its id differs, so the plan creates instead of adopting it.grants/schemas/change_name(from Re-key grants when their parent's ID changes #7345) now shows the in-place rename;migrate/auto/schema-renamenow renames;lifecycle/prevent-destroyswitched its recreate lever from name tocatalog_name.addParentMoves,followsParentRename,Changes.HasOnlySingleReasonand the skipped internal-ID changes.This pull request and its description were written by Isaac.