dennismdejong opened a new pull request, #13714:
URL: https://github.com/apache/gravitino/pull/13714
### What changes were proposed in this pull request?
`GET /api/metalakes` now returns an `owner` for every listed metalake:
```json
{
"name": "metalake_a",
"comment": null,
"properties": null,
"audit": { "creator": "admin", "createTime": "..." },
"owner": { "name": "alice", "type": "user" }
}
```
- `MetalakeDTO` gains a nullable `owner` (`OwnerDTO`) plus
`withOwner(...)`/`owner()`, owner-aware `equals`/`hashCode`, and
`@JsonInclude(ALWAYS)` so the field is serialized as an explicit `null` instead
of disappearing under the server's `NON_NULL` mapper.
- `MetalakeOperations.listMetalakes()` resolves ownership **after**
`MetadataAuthzHelper.filterMetalakes(...)`, so only metalakes the caller can
see are looked up (one `OwnerDispatcher.getOwner(...)` call per visible
metalake). Ownership is `null` when authorization is disabled or no owner is
assigned.
- The Java client forwards the owner into `GravitinoMetalake`, so
`client.listMetalakes()[i].owner()` works; the CLI and the MCP `list_metalakes`
tool forward the REST payload and pick the field up for free (the MCP tool
documentation now lists it).
- Docs: new `owner` property on the `Metalake` OpenAPI schema, and the
documented owner `type` enum/example are corrected to the lower-case
`user`/`group` values the server already emits.
- `clients/cli` declares `jackson.annotations` explicitly: it compiles with
`-Werror` and otherwise fails on `unknown enum constant Include.ALWAYS` for the
inherited field.
### Why are the changes needed?
Clients that display ownership alongside the metalake list had to issue one
owner request per metalake. Supporting user and group owners directly in the
list removes that N+1 pattern, and an explicit `null` distinguishes
"authorization disabled / no owner assigned" from "field unsupported". All
existing response fields are retained.
Fix: #13127
### Does this PR introduce _any_ user-facing change?
Yes. Each entry returned by `GET /api/metalakes` (and the Java client's
`listMetalakes()`) includes `owner: {"name": ..., "type": "user"|"group"}` or
`owner: null`. Because `MetalakeDTO` is shared, single-metalake responses
(`GET`/`POST`/`PATCH`) also serialize `owner: null`, since those operations do
not load ownership. Responses without the field still deserialize.
### How was this patch tested?
- `./gradlew :common:test :server:test :server-common:test
:clients:client-java:test` — 519 / 565 / 381 / 408 tests, 0 failures.
- `TestMetalakeOperations` covers user and group owners, explicit `null`
when no owner is assigned, explicit `null` when authorization is disabled, and
that an invisible metalake's owner is never resolved (mock authorizer +
`verify(owners, never())`), using the production `ObjectMapperProvider`.
- `TestDTOJsonSerDe` covers owner round-trip for both owner types,
equality/hashCode, and deserialization of legacy JSON without the field.
- `TestGravitinoAdminClient` covers owner propagation through
`listMetalakes()`.
- `./gradlew :clients:cli:test -PskipITs` — 507 tests, 0 failures;
`:clients:cli:javadoc` and `:docs:build` (Redocly OpenAPI lint) pass.
- `:mcp-server:formatCheckPython`, `:mcp-server:pylint` (10.00/10) and the
MCP unit tests (277 passed).
- Spotless checks pass for all touched modules.
--
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]
