amogh-jahagirdar commented on code in PR #10202:
URL: https://github.com/apache/iceberg/pull/10202#discussion_r1776236397
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2893,6 +3003,37 @@ components:
additionalProperties:
type: string
+ AppendDataFileRequest:
+ type: object
+ required:
+ - data-files
+ properties:
+ identifier:
+ allOf:
+ - $ref: '#/components/schemas/TableIdentifier'
+ description: Table identifier to update; must be present for
CommitTransactionRequest
+ accept-delay-ms:
Review Comment:
I agree, I think a clients specifying ends up leading to even more
complexity since questions like @dramaticlly asked
[here](https://github.com/apache/iceberg/pull/10202/files#r1589712625)
naturally come up.
I think it makes sense just to exclude this. Catalog implementations can
define their own SLAs and clients themselves can take whatever action they want
if a certain amount of time has passed and the append wasn't committed. See my
note
[here](https://github.com/apache/iceberg/pull/10202#discussion_r1776223142) on
how clients can take action. That keeps the spec minimal and gets us out of the
"what do we do if the SLA is breached" question since that's really use case
specific.
The spec would still be really useful without it since I think the main
problem to solve is being able to offload the appends to services which have
full visibility on ongoing appends and can run operations efficiently to
minimize contention and ideally maximize throughput.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
