+1 for keeping the name as-is with explicit documentation.

(I too don't love the name, but it doesn't seem worth the effort of a
breaking change)

On Thu, Sep 11, 2025 at 10:18 AM Steven Wu <[email protected]> wrote:

> > 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
>>>>
>>>

Reply via email to