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 <russell.spit...@gmail.com> wrote: > +1, I also am fine with the name. > > On Wed, Sep 10, 2025 at 10:30 PM Steven Wu <stevenz...@gmail.com> 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 >> >
