> I lean towards keeping it as "added-rows" and documenting very clearly what it actually is.
Christian, that is the approach we are taking in the PR. Feedback so far suggests that the overhead/impact of renaming outweighs the benefit. We will just focus on clarifying the spec and Javadoc On Thu, Sep 11, 2025 at 9:58 AM Christian Thiel <[email protected]> wrote: > I am unsure about the name. I like "assigned-rows" much more as a name. > Changing the name later however would be a problem for the REST Spec > (currently neither added-rows nor assigned-rows is in it). Renaming the > field for v4 would be a breaking change for the rest spec which should be > avoided - unless we send "added-rows" indefinitely. Deviating with REST > from the spec also isn't nice. > I lean towards keeping it as "added-rows" and documenting very clearly > what it actually is. > > On Thu, 11 Sept 2025 at 16:55, Russell Spitzer <[email protected]> > wrote: > >> +1, I also am fine with the name. >> >> On Wed, Sep 10, 2025 at 10:30 PM Steven Wu <[email protected]> wrote: >> >>> >>> In the 1.10.0 RC5 voting thread >>> <https://lists.apache.org/thread/rt4tk652wmw5ht9gb34dhrx1gwgolzkh>, >>> Christian brought up an inconsistency issue between the spec and the Java >>> implementation. Spec removed the `added-rows` while the Java implementation >>> continued to use and encode it. >>> >>> After some discussion, the consensus is to bring it back in the spec. >>> Otherwise, the REST catalog server would need to read the manifest list >>> file to compute the number to increment the table's next-row-id when >>> writing metadata.json. This would also restore the consistency between the >>> spec and Java impl. >>> >>> The field name is not accurate anymore. It should actually be >>> `assigned-rows`. But for compatibility reasons, we think it is better to >>> keep it as it is. We will clarify its purpose in the spec language. >>> >>> Here is the PR that rectifies the spec. >>> https://github.com/apache/iceberg/pull/14048 >>> >>> Thanks, >>> Steven >>> >>
