anoopj commented on code in PR #16408:
URL: https://github.com/apache/iceberg/pull/16408#discussion_r3336321820
##########
core/src/main/java/org/apache/iceberg/TrackingStruct.java:
##########
@@ -249,95 +254,43 @@ protected <T> void internalSet(int pos, T value) {
}
}
- static Builder builder() {
- return new Builder();
+ /** Creates a builder for a newly added file in the given snapshot. */
+ static TrackingBuilder added(long snapshotId) {
+ return new TrackingBuilder(snapshotId);
+ }
+
+ /**
+ * Creates a builder for a tracking row derived from {@code source} at the
current snapshot.
+ *
+ * <p>Without MODIFIED status, this produces an EXISTING row. Once MODIFIED
lands, the status will
+ * be auto-derived from the source, the snapshot, and which mutation methods
are called.
+ */
+ // TODO: when MODIFIED is added, derive status from source +
currentSnapshotId + mutations.
+ static TrackingBuilder builder(Tracking source, long currentSnapshotId) {
Review Comment:
I think you are correct that there is an asymmetry in the API between
terminal status and the modified/existing status.
The deeper question you're asking is whether implicit status derivation is
a design philosophy is good idea in this builder. Builders are typically used
in the write path where correctness is important for data durability. My
personal preference is to keep it in the builder since there is business logic
to figure out the right status between `ADDED/EXISTING/MODIFIED`. It is better
to consolidate the logic in the builder such that callers can't make mistakes.
--
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]
