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.
