You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Christian Thiel <ch...@gmail.com> on 2025/12/04 14:59:40 UTC
[DISCUSS] REST: Add etag to CommitTableResponse
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
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Kevin Liu <ke...@apache.org>.
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 <ga...@apache.org> 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 <ke...@apache.org> 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 <jz...@apache.org> wrote:
>>
>>> Make sense
>>>
>>> John Zhuge
>>>
>>>
>>> On Thu, Dec 4, 2025 at 11:19 PM huaxin gao <hu...@gmail.com>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner <
>>>> etudenhoefner@apache.org> wrote:
>>>>
>>>>> Makes sense to add this, so +1
>>>>>
>>>>> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <fl...@gmail.com> 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 <
>>>>>> christian.t.b101@gmail.com> 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 <ga...@apache.org>
>>>>>>> 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 <ch...@gmail.com> 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
>>>>>>>>>
>>>>>>>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Gábor Kaszab <ga...@apache.org>.
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 <ke...@apache.org> 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 <jz...@apache.org> wrote:
>
>> Make sense
>>
>> John Zhuge
>>
>>
>> On Thu, Dec 4, 2025 at 11:19 PM huaxin gao <hu...@gmail.com>
>> wrote:
>>
>>> +1
>>>
>>> On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner <
>>> etudenhoefner@apache.org> wrote:
>>>
>>>> Makes sense to add this, so +1
>>>>
>>>> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <fl...@gmail.com> 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 <
>>>>> christian.t.b101@gmail.com> 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 <ga...@apache.org>
>>>>>> 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 <ch...@gmail.com> 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
>>>>>>>>
>>>>>>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Kevin Liu <ke...@apache.org>.
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 <jz...@apache.org> wrote:
> Make sense
>
> John Zhuge
>
>
> On Thu, Dec 4, 2025 at 11:19 PM huaxin gao <hu...@gmail.com> wrote:
>
>> +1
>>
>> On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner <
>> etudenhoefner@apache.org> wrote:
>>
>>> Makes sense to add this, so +1
>>>
>>> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <fl...@gmail.com> 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 <
>>>> christian.t.b101@gmail.com> 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 <ga...@apache.org>
>>>>> 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 <ch...@gmail.com> 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
>>>>>>>
>>>>>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by John Zhuge <jz...@apache.org>.
Make sense
John Zhuge
On Thu, Dec 4, 2025 at 11:19 PM huaxin gao <hu...@gmail.com> wrote:
> +1
>
> On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner <
> etudenhoefner@apache.org> wrote:
>
>> Makes sense to add this, so +1
>>
>> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <fl...@gmail.com> 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 <
>>> christian.t.b101@gmail.com> 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 <ga...@apache.org>
>>>> 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 <ch...@gmail.com> 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
>>>>>>
>>>>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Péter Váry <pe...@gmail.com>.
+1
huaxin gao <hu...@gmail.com> ezt írta (időpont: 2025. dec. 5., P,
8:18):
> +1
>
> On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner <
> etudenhoefner@apache.org> wrote:
>
>> Makes sense to add this, so +1
>>
>> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <fl...@gmail.com> 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 <
>>> christian.t.b101@gmail.com> 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 <ga...@apache.org>
>>>> 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 <ch...@gmail.com> 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
>>>>>>
>>>>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by huaxin gao <hu...@gmail.com>.
+1
On Thu, Dec 4, 2025 at 10:55 PM Eduard Tudenhöfner <et...@apache.org>
wrote:
> Makes sense to add this, so +1
>
> On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <fl...@gmail.com> 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 <
>> christian.t.b101@gmail.com> 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 <ga...@apache.org>
>>> 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 <ch...@gmail.com> 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
>>>>>
>>>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Eduard Tudenhöfner <et...@apache.org>.
Makes sense to add this, so +1
On Thu, Dec 4, 2025 at 6:42 PM Yufei Gu <fl...@gmail.com> 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 <ch...@gmail.com>
> 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 <ga...@apache.org> 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 <ch...@gmail.com> 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
>>>>
>>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Yufei Gu <fl...@gmail.com>.
+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 <ch...@gmail.com>
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 <ga...@apache.org> 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 <ch...@gmail.com> 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
>>>
>>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Christian Thiel <ch...@gmail.com>.
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 <ga...@apache.org> 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 <ch...@gmail.com> 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
>>
>>
Re: [DISCUSS] REST: Add etag to CommitTableResponse
Posted by Gábor Kaszab <ga...@apache.org>.
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 <ch...@gmail.com> 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
>
>