Hi Kevin, Thanks for the thorough writeup. Basically, ETag makes sense in response messages that contain table metadata, meaning CreateTableResponse, LoadTableResponse and CommitTableResponse. This is going to be covered now entirely.
For views, I haven't made any analysis whether it makes sense to introduce freshness-aware loading (including ETag and If-None-Match headers and 304 response). Not sure how much we'd gain to save an empty response with 304 vs sending a full LoadViewResponse. I think let's finish the back-to-back implementation for tables and we can get back to views once that's finalized. Cheers, Gabor Kevin Liu <[email protected]> ezt írta (időpont: 2025. dec. 5., P, 21:39): > Thanks for bringing this up, Christian. > > I double-checked the spec, specifically where we use the `metadata` and > `metadata-location` fields. My assumption is that these are the places > where we want to include etag. > > For example, following the `metadata-location` field (note: the `metadata` > field overlaps with the same objects): > ``` > metadata-location > LoadTableResult -> LoadTableResponse / CreateTableResponse > CommitTableResponse > LoadViewResult -> LoadViewResponse > > RegisterTableRequest > ``` > > `LoadTableResponse` and `CreateTableResponse` are already covered. > `CommitTableResponse` is missing and addressed by your PR [1] and vote > thread. > We might want to add the etag field to `LoadViewResponse`. > And `RegisterTableRequest` can be ignored since it's a request object. > > Let me know what you think about adding etag to `LoadViewResponse`. > > Best, > Kevin Liu > > > [1] https://github.com/apache/iceberg/pull/14760 > > > > On Fri, Dec 5, 2025 at 8:03 AM John Zhuge <[email protected]> wrote: > >> Make sense >> >> John Zhuge >> >> >> On Thu, Dec 4, 2025 at 11:19 PM huaxin gao <[email protected]> >> wrote: >> >>> +1 >>> >>> On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner < >>> [email protected]> wrote: >>> >>>> Makes sense to add this, so +1 >>>> >>>> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <[email protected]> wrote: >>>> >>>>> +1. There’s no known reason to exclude it, adding the ETag to >>>>> CommitTableResponse feels like a natural and consistent extension of the >>>>> existing behavior. >>>>> >>>>> Yufei >>>>> >>>>> >>>>> On Thu, Dec 4, 2025 at 8:33 AM Christian Thiel < >>>>> [email protected]> wrote: >>>>> >>>>>> Hey Gábor, >>>>>> Thanks for the Feedback! I'll give it another day for others to chime >>>>>> in and otherwise start the vote. >>>>>> I am currently at a point where I need it in Rust and was >>>>>> surprised it wasn't there :) >>>>>> >>>>>> Best, >>>>>> Christian >>>>>> >>>>>> On Thu, 4 Dec 2025 at 16:39, Gábor Kaszab <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>> There is no particular reason ETag is not included in the >>>>>>> CommitTableResponse in the spec. In fact the reference IRC already >>>>>>> returns >>>>>>> ETag on that endpoint. I also had it in mind to extend the spec with >>>>>>> this, >>>>>>> I just wanted to finish the implementation of using ETags on the client >>>>>>> side for the loadTable endpoint (side note, it's open for review >>>>>>> <https://github.com/apache/iceberg/pull/14398>, any feedback is >>>>>>> appreciated!). In terms of implementation, it is not that trivial to >>>>>>> implement the usage of the ETag after a RESTTableOperations.commit() / >>>>>>> refresh(), but this is another story, just the reason I wasn't in a rush >>>>>>> extending the ETag support further in the REST spec. >>>>>>> >>>>>>> Long story short, I'm +1 on this! >>>>>>> Gabor >>>>>>> >>>>>>> Christian Thiel <[email protected]> ezt írta (időpont: >>>>>>> 2025. dec. 4., Cs, 16:00): >>>>>>> >>>>>>>> Dear all, >>>>>>>> I noticed that we currently don't return an etag after single table >>>>>>>> commits. >>>>>>>> As of now, etags are returned for CreateTableResponse and >>>>>>>> LoadTableResponse. I browsed the original doc [1], the PR [2], the >>>>>>>> mailing >>>>>>>> List and my brain but couldn't find a discussion around this. >>>>>>>> >>>>>>>> Is anyone aware of a reason why we didn't include >>>>>>>> CommitTableResponse? >>>>>>>> If not I would start a vote on [3] to include it. >>>>>>>> >>>>>>>> Best, >>>>>>>> Christian >>>>>>>> >>>>>>>> [1] >>>>>>>> https://docs.google.com/document/d/1rnVSP_iv2I47giwfAe-Z3DYhKkKwWCVvCkC9rEvtaLA >>>>>>>> [2] https://github.com/apache/iceberg/pull/11946 >>>>>>>> [3] https://github.com/apache/iceberg/pull/14760 >>>>>>>> >>>>>>>>
