[Subtask] Complete V3 type compatibility for the Hudi catalog
- Dominant language
- Java
- Stars
- 3.2k
- Forks
- 935
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 298
Description
### Describe the subtask
Complete and document the five-family compatibility contract for the Hudi 0.15 catalog, whose current Gravitino surface is read-only.
**Compatibility outcomes**
- **Nanosecond timestamps:** Reject before backend invocation.
- **Variant:** Reject before backend invocation.
- **Unknown/Null:** Reject before backend invocation.
- **Geometry:** Reject before backend invocation.
- **Geography:** Reject before backend invocation.
**Acceptance**
- Reproduce all five families through the connector's public create/conversion path and its alter/load paths where supported.
- A supported mapping must round-trip without losing type identity or parameters.
- An unsupported mapping must return `IllegalArgumentException` before external metadata mutation; no fallback to a narrower or opaque type is allowed.
- Cover nested types where the connector supports complex columns.
- Add focused converter/operation tests and an integration or no-side-effect test appropriate to the connector.
- Update the connector documentation with a five-family compatibility matrix and rejection rationale.
- Keep implementation commits atomic by connector and type family.
**Connector-specific verification**
Reproduce through `HudiCatalogOperations.createTable`. Verify an in-memory backend is never called and no table exists afterward, then run the focused and full module suites.
**Documentation**
`docs/lakehouse-hudi-catalog.md`
### Parent issue
#12056
Contributor guide
Assessment
This issue has not been assessed yet.