I'm +0. I definitely agree with the premise that we need a spec change to ensure added rows exist at the snapshot level for row lineage, but I feel like there is an advantage to just formalizing the added-records snapshot summary property, and make it required for writers in case row lineage is enabled on the table. The advantage is that in the ecosystem more implementations are likely to populate the summary already (beyond the Java implementation, I see Python does as well) so for those implementations, the lift to support row lineage is a little bit reduced since the field will probably already be populated. It also avoids any awkwardness around having 2 of essentially the same field in metadata.
In the end, I think that is a minor advantage so I'm not very opinionated on this. We're talking about one field, and the additional lift for that is some slightly additional parsing handling in implementations which in the grand scheme of things is a smaller portion of the work involved. I also understand the argument that it's awkward to have required fields be in the summary in the first place (thinking back to our discussions around operation handling). Thanks, Amogh Jahagirdar On Thu, Jan 16, 2025 at 2:52 PM Prashant Singh <prashant010...@gmail.com> wrote: > +1 (non-binding) ! > > Best, > Prashant Singh > > On Thu, Jan 16, 2025 at 1:14 PM Daniel Weeks <dwe...@apache.org> wrote: > >> +1 >> >> On Thu, Jan 16, 2025 at 10:39 AM Steve Zhang >> <hongyue_zh...@apple.com.invalid> wrote: >> >>> Thank you Russell! +1 (non-binding) >>> >>> Thanks, >>> Steve Zhang >>> >>> >>> >>> On Jan 15, 2025, at 10:53 PM, huaxin gao <huaxin.ga...@gmail.com> wrote: >>> >>> +1 (non-binding) >>> >>> >>>
