dennismdejong opened a new pull request, #13713:
URL: https://github.com/apache/gravitino/pull/13713
### What changes were proposed in this pull request?
`CommonUtil.normalizeToken` now canonicalizes a mode/behavior token by
trimming it, dropping
underscores and upper-casing it, and `CommonUtil.parseEnumToken` resolves
that canonical form
against the enum constants instead of calling `Enum.valueOf` on the raw
upper-cased token:
```java
public static String normalizeToken(String value) {
return value == null ? "" : value.trim().replace("_",
"").toUpperCase(Locale.ROOT);
}
```
`EXIST_OK`, `ExistOk`, `exist_ok` and `existok` therefore all parse as
`EXIST_OK` on
`CreateNamespace` and `CreateTable`, which is what the lance-namespace spec
declares ("Case
insensitive, supports both PascalCase and snake_case").
Separators are dropped rather than inserted at camel-case boundaries on
purpose:
`normalizeToken` is also the comparison key used by
`LanceMetadataAuthorizationMethodInterceptor.OverwriteAuthzHandler`
(`OVERWRITE_MODE.equals(normalizeToken(mode))`).
Case-boundary insertion would turn a token like ` OverWrite ` into
`OVER_WRITE`, so the interceptor
would authorize it as a plain create while the operation performs an
overwrite — the privilege gap
that handler exists to close. Both callers keep sharing the single
normalization function, so a
token is classified identically wherever it is read. The mode/behavior
vocabulary stays
collision-free under canonicalization: `CREATE`/`EXISTOK`/`OVERWRITE`,
`FAIL`/`SKIP`,
`RESTRICT`/`CASCADE`, `REGISTER`.
The property handed to the catalog is unaffected: `normalizeCreateMode`
stores
`parseEnumToken(...).name()`, so `mode=ExistOk` still writes
`lance.creation-mode=EXIST_OK` for
`LanceTableOperations.CreationMode.valueOf`.
Docs: `docs/lance-rest-service.md` now states that an underscore in a
multi-word mode value is
optional and gives the accepted spellings.
### Why are the changes needed?
A client that follows the spec's own example spelling (`ExistOk`) could not
create a namespace or a
table idempotently and had to discover the snake_case spelling by trial:
```
lance_namespace.errors.InvalidInputError: Invalid input: Unknown create
namespace mode: ExistOk
```
snake_case worked, so the spec's "supports both" promise held for exactly
one of the two spellings.
`ExistOk` is the only multi-word constant in the vocabulary, which is why
nothing else was affected.
Fix: #13680
### Does this PR introduce _any_ user-facing change?
Yes: `CreateNamespace` and `CreateTable` now accept the PascalCase spelling
of a mode value, and a
multi-word mode value tolerates any casing/spacing of its letters.
Previously accepted spellings
(`create`, `exist_ok`, `EXIST_OK`, `Overwrite`, ...) keep working; no value
that used to be rejected
becomes ambiguous, and error messages are unchanged.
### How was this patch tested?
-
`TestGravitinoLanceModeParsing#testParseEnumTokenAcceptsBothSpellingsOfMultiWordValues`
covers
`ExistOk`, `exist_ok`, `EXIST_OK`, `existok` and ` existOk ` against the
parser.
-
`TestGravitinoLanceModeParsing#testCreateNamespaceModeAcceptsPascalCaseExistOk`
and
`#testCreateTableModeAcceptsPascalCaseExistOk` cover the two operation
paths reported in the
issue, including that the table property is stored as `EXIST_OK`.
- `LanceRESTServiceIT#testCreateNamespace` and `#testCreateTable` now call
the REST API with
`mode="ExistOk"` for a catalog, a schema and a table. On the unpatched
`CommonUtil` both tests
fail with exactly the reported errors (`Unknown create namespace mode:
ExistOk`, `Unknown create
table mode: ExistOk`); with the patch they pass.
- `TestLanceMetadataAuthorizationMethodInterceptor` now also feeds
`over_write` through the
overwrite-authorization path, pinning that authorization reads the mode
the way the operation
does.
- Run: `./gradlew :lance:lance-common:test :lance:lance-rest-server:test`
(unit suites pass,
`spotlessJavaCheck` clean) and
`./gradlew :lance:lance-rest-server:test -PskipTests -PtestMode=embedded
--tests "*LanceRESTServiceIT"`
(15/15 pass).
--
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]
