rdblue commented on pull request #2957: URL: https://github.com/apache/iceberg/pull/2957#issuecomment-920477110
I was imagining the builder would work a little differently. There's definitely some value in the regular builder pattern where you can mostly copy fields and just make calls to change values. But I think adding a builder could bring more value if we actually moved the implementations of the `TableMetadata` modifications into the builder. So what I was thinking was to basically move all of the methods like `replaceCurrentSnapshot` and `removeSnapshotsIf` into the builder itself. That approach allows us to make more than one change without adding special handling for `upgradeToFormatVersion`. We could chain changes to produce a new `TableMetadata` because the methods keep track of table state. A second benefit that I'm interested in is tracking the high-level changes the led to a new `TableMetadata` object. We're building a REST-based catalog and I think this is the first step to an update that posts just what changed. For example, `replaceCurrentSnapshot` could produce a new `TableMetadata`, but also keep track of the facts that (1) a new snapshot was added and (2) the current snapshot was set to that snapshot's ID. Those granular changes make a REST protocol much more efficient. Does that motivation make sense? -- 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]
