Sounds good to me! Thanks for the analysis. I'll follow up on the "freshness-aware table loading" PR [1] you have open.
Best, Kevin Liu [1] https://github.com/apache/iceberg/pull/14398 On Sat, Dec 6, 2025 at 12:24 AM Gábor Kaszab <[email protected]> wrote: > 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 >>>>>>>>> >>>>>>>>>
