weiqingy opened a new pull request, #28717: URL: https://github.com/apache/flink/pull/28717
## What is the purpose of the change This pull request persists the top-level field names of a `RowData` state serializer in `RowDataSerializerSnapshot`, so they survive a save/restore round-trip. Today the snapshot stores the field types but not the names. It is a self-contained, shared building block: the names are needed by schema-aware consumers — the State Catalog (FLIP-599) to expose a readable schema for keyed state, and name-based schema evolution (FLIP-527). They are written unconditionally and decoupled from any evolution logic, so whichever effort lands first establishes a single snapshot format. ## Brief change log - Add a nullable top-level `String[] fieldNames` to `RowDataSerializer`, threaded through `duplicate()` and the snapshot round-trip; `equals`/`hashCode` are unchanged (names derive from the types). - Bump `RowDataSerializerSnapshot` from V3 to V4, appending the names block after the existing types / nested-serializer section. `readSnapshot` reads the names only for `readVersion >= 4`, so V4 readers still restore V3 snapshots (names absent -> `null`). - `InternalSerializers` builds the ROW serializer with its top-level field names (split from the structured-type case, which stays name-less). ## Verifying this change This change added tests and can be verified as follows: - V4 snapshot round-trip preserves the top-level names, and nested `ROW` field names remain recoverable from the child logical types. - Genuine V3 -> V4 backward compatibility: a hand-crafted V3-layout snapshot restores with `fieldNames == null` and the serializer still round-trips. - `InternalSerializers.create(<a RowType>)` yields a serializer whose snapshot carries the names unconditionally. - `duplicate()` preserves the names. - `resolveSchemaCompatibility` is unchanged: a field-type-array difference still returns `incompatible()` regardless of names. ## Does this pull request potentially affect one of the following parts: - Dependencies (does it add or upgrade a dependency): no - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no - The serializers: yes — `RowDataSerializer` / `RowDataSerializerSnapshot`, snapshot format V3 -> V4 - The runtime per-record code paths (performance sensitive): no - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: yes — the `RowData` state snapshot format moves V3 -> V4. Backward compatible: V4 readers restore V3 snapshots (names absent -> `null`); no runtime behavior change. - The S3 file system connector: no ## Documentation - Does this pull request introduce a new feature? no — it persists metadata not yet consumed by any decision; no user-facing behavior change. - If yes, how is the feature documented? not applicable ##### Was generative AI tooling used to co-author this PR? - [X] Yes (Claude Code, Claude Opus 4.8) Generated-by: Claude Code (Claude Opus 4.8) -- 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]
