jun-he commented on a change in pull request #2284:
URL: https://github.com/apache/iceberg/pull/2284#discussion_r609381706
##########
File path: core/src/main/java/org/apache/iceberg/TableMetadata.java
##########
@@ -529,7 +530,8 @@ public TableMetadata updatePartitionSpec(PartitionSpec
newPartitionSpec) {
.addAll(specs);
if (!specsById.containsKey(newDefaultSpecId)) {
// get a fresh spec to ensure the spec ID is set to the new default
- builder.add(freshSpec(newDefaultSpecId, schema, newPartitionSpec));
+ builder.add(freshSpec(newDefaultSpecId, schema, newPartitionSpec,
formatVersion,
+ specs, new AtomicInteger(lastAssignedPartitionId)));
Review comment:
@rdblue I updated the PR accordingly.
Seems the logic of `reassignPartitionIds` can only work for V2 table.
For V1 table, if a table has a schema with a single field `ts` and is
partitioned by `1000: ts_day=day(ts)` and then is replaced with a new schema
with a single field `id` and is partitioned by `1000: id_bucket=bucket(16,
id)`, it cannot reassign spec including `1000: ts_day=null` and `1001:
id_bucket=bucket(16, id)` because the new schema does not contain `ts` any
more.
Therefore, I kept `reassignPartitionIds` to be no op in the PR, which is the
current behavior for V1 table.
How do you feel about this?
--
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]
