rdblue commented on a change in pull request #1373:
URL: https://github.com/apache/iceberg/pull/1373#discussion_r479586930
##########
File path: core/src/main/java/org/apache/iceberg/TableMetadata.java
##########
@@ -598,20 +649,38 @@ public TableMetadata buildReplacement(Schema
updatedSchema, PartitionSpec update
builder.add(freshSpec);
}
+ // determine the next order id
+ int maxOrderId =
sortOrders.stream().mapToInt(SortOrder::orderId).max().orElse(INITIAL_SORT_ORDER_ID);
+ int nextOrderId = maxOrderId + 1;
Review comment:
This is used when we are running a `REPLACE TABLE` operation. We want to
keep the history, but the schema and partition spec can be completely new. When
the schema and partition spec are new, we assign fresh IDs to the schema and
rebuild the partition spec (and sort order) to use the newly assigned IDs.
That's why we use the `freshSpec` and `freshSortOrder` methods here as well as
when creating new table metadata -- because we don't trust the IDs that were
assigned in the schema that was passed in.
I should note that when we update a schema, we also rebuild the specs and
sort orders. But in those cases, the IDs aren't what we are changing. What may
change are the fields in the schema. Fields could be renamed, or dropped. What
we're primarily looking for is when a field is dropped. Then rebuilding the
order or spec will hit a validation exception.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
