rdblue commented on pull request #2240: URL: https://github.com/apache/iceberg/pull/2240#issuecomment-786785988
My concern isn't modifying table properties specifically. We need to do that so that we update the properties to reflect the user's intent. If we have a setting for a column, renaming the property to carry it through a column rename is preserving the user's intent. But if we update table properties then we are potentially losing what the user chose to do. For example, what do we do when the sort field is removed and there is a metrics config property? We can't remove a `truncate[16]` setting because we don't know whether it was added when the field was added to the sort, or if it was specifically set by the table owner. Similarly, we have cases where the owner may set a field to `counts` and then add it to the sort. I think that the table owner's config should take precedence. So we don't replace the property, but how then does the owner signal that it should be defaulted instead? Last, how do we handle tables that currently have sort orders? If we base metrics on the current sort order then everything starts working automatically. If we don't, then we would need to trigger a commit to update the properties. Even if we don't pass the table around, I think we should definitely pass the sort order in to get the metrics config. It is probably not the time to refactor and pass the table, but we can pass the sort order like we do the other table config. ---------------------------------------------------------------- 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]
