Hello, Thanks for the review. I have addressed the comments in the latest draft: https://docs.google.com/document/d/1REmpQ2r5W12OvW2CU9tNjDWjpkFJegiTZnE1IZbBH_U/edit?tab=t.0
1. The ambiguous delete-encoding validation was removed. Format-version compatibility is checked before table creation, while delete semantics are handled by the Iceberg reader during bootstrap. 2. Nested identifier fields are rejected during Coordinator-side validation. Only top-level identifier fields are supported. 3. Two bucket-mapping examples were added, covering both day(ts), bucket(16, id) and day(ts) without an Iceberg bucket transform. Thanks, Liting ________________________________ 发件人: Muhammet Orazov via dev <[email protected]> 发送时间: 2026年7月1日 21:21 收件人: [email protected] <[email protected]> 抄送: Muhammet Orazov <[email protected]> 主题: Re: 回复: [DISCUSS] Draft design: Support upgrading existing Iceberg tables to Fluss tables Hello Liting, Thanks for the design draft! I have couple questions/clarifications on top of the latest addressed version. 1) > If the selected Iceberg reader cannot guarantee correct > snapshot-visible rows for a table that contains equality deletes, > position deletes, deletion vectors, or any other delete encoding, > create_from_lake rejects the table with a clear validation error. For me this is not clear, if above check happens on validation phase or discovered once the selected reader is running. 2) > Iceberg tables with non-empty identifier fields are mapped to Fluss > primary-key tables and then follow the same bootstrap pipeline as > FIP-25. The Iceberg identifier fields may be nested in structs, how would we map these identifier fields? I assume it will be rejected. 3) For the Bucket Configuration section, it would help to add some examples. Iceberg with combined partitioning: `day(ts), bucket(16, id)` and identifier field `id`, how this will be transformed into Fluss PK table? Maybe good idea to add some examples, given iceberg partitioning combinations to the Fluss tables mapping.
