Use X-Databricks-Workspace-Id for workspace routing#805
Open
Divyansh-db wants to merge 2 commits into
Open
Conversation
Mechanical regen of every `*Impl.java` after the `javasdkv0` template was updated to emit `X-Databricks-Workspace-Id` in place of `X-Databricks-Org-Id` on workspace-scoped operations. 149 files, 961 insertions / 961 deletions — symmetric swap with no logic change. Account-scoped impls are unaffected; the conditional gate (`if not .Service.IsAccounts`) and value source (`apiClient.workspaceId()`) are unchanged. Signed-off-by: Divyansh Vijayvergia <divyansh.vijayvergia@databricks.com>
Covers the sources the Java SDK generator does not touch: * Deprecated SCIM v1 impls (GroupsImpl, ServicePrincipalsImpl, UsersImpl) retain a codegen marker but are maintained by hand. * SharesExtImpl, the hand-written extension for `/api/2.1/unity-catalog/shares`. * The X-Databricks-Org-Id literal in the UnifiedHostWorkspaceIT comment. * DatabricksConfig.workspaceId Javadoc widened to note the value accepts either a classic numeric workspace ID or another workspace identifier format that the server understands. * NEXT_CHANGELOG.md entry under Internal Changes. Signed-off-by: Divyansh Vijayvergia <divyansh.vijayvergia@databricks.com>
Divyansh-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Divyansh-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Contributor
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
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
1 participant
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.
Summary
Workspace-scoped API calls now identify the target workspace via the
X-Databricks-Workspace-Idheader instead ofX-Databricks-Org-Id. The value source is unchanged: it still comes fromDatabricksConfig.setWorkspaceId()(or theDATABRICKS_WORKSPACE_IDenvironment variable).Why
On unified Databricks hosts that serve multiple workspaces, the SDK sends a routing header on every workspace-scoped HTTP request so the gateway can dispatch it to the correct workspace. Until now that header was
X-Databricks-Org-Id.The Databricks platform is consolidating workspace addressing onto a single header,
X-Databricks-Workspace-Id, which accepts a broader range of workspace identifier formats and replaces the older single-purpose channels going forward. The previous header continues to be accepted by the platform, so older SDK versions keep working, but new SDK versions should use the new name.This PR is the Java SDK's part of that migration.
What changed
Interface changes
None.
DatabricksConfig#workspaceIdkeeps the same field name, type (String), accessors, and environment variable (DATABRICKS_WORKSPACE_ID). The Javadoc is widened to note that the value may now be either a classic numeric workspace ID or another workspace identifier format that the server understands.Behavioral changes
X-Databricks-Org-Id. They now sendX-Databricks-Workspace-Id(with the same value, gated onapiClient.workspaceId()being non-null). Account-scoped requests are unaffected.Internal changes
*Impl.javaunderdatabricks-sdk-java/src/main/java/com/databricks/sdk/service/*/and the test fixtures underdatabricks-sdk-java/src/test/java/com/databricks/sdk/service/{httpcallv2,idempotencytesting,jsonmarshallv2,lrotesting}/from the corresponding generator template change: 149 files, 961 line swaps — symmetric, no logic change.GroupsImpl,ServicePrincipalsImpl,UsersImpl) and theSharesExtImplextension for/api/2.1/unity-catalog/shares.X-Databricks-Org-Idreference inside theUnifiedHostWorkspaceITcomment so the comment matches the new code.How is this tested?
make fmtandmvn clean testpass locally. Full unit suite is green (1376 passed, 0 failed).Mirrors databricks/databricks-sdk-go#1688.