wombatu-kun commented on code in PR #17137:
URL: https://github.com/apache/iceberg/pull/17137#discussion_r3556016657
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3930,6 +3937,9 @@ components:
CreateTableRequest:
type: object
+ description:
+ Table creation request. The field IDs in `schema` are assigned by the
client, but because a newly
+ created table has no committed data, a server MAY (re)assign them when
creating the table.
Review Comment:
The reference server already performs exactly this remap on create, and it
does it by name: `TableMetadata.newTableMetadata` freshens ids via
`TypeUtil.assignFreshIds`, rebuilds the partition spec through
`schema.findColumnName(field.sourceId())` against the fresh schema, and
rebuilds the sort order the same way
(`core/src/main/java/org/apache/iceberg/TableMetadata.java:120-138`, `:828`);
`identifier-field-ids` are re-derived by name in
`TypeUtil.refreshIdentifierFields`
(`api/src/main/java/org/apache/iceberg/types/TypeUtil.java:338`).
On unifying the two cases under "its actions must not alter the table data":
that invariant is vacuous for `CreateTableRequest`, because no table data
exists yet. It is satisfied by a server that reassigns field ids and leaves the
submitted `partition-spec`, `write-order`, and `identifier-field-ids` pointing
at the old ids, which is the case being asked about here. Either the create
side names the remap explicitly, or the invariant has to cover submitted
metadata that references field ids and not just data.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
