sungwy commented on code in PR #13879:
URL: https://github.com/apache/iceberg/pull/13879#discussion_r3607554756
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3260,6 +3260,71 @@ components:
additionalProperties:
type: string
+ ReadRestrictions:
+ type: object
+ description: >
+ Read restrictions for a table, including projection and row filter
expressions, according to the current schema.
+
+ A client MUST enforce the restrictions defined in this object when
reading data
+ from the table.
+
+ These restrictions apply only to the authenticated principal, user,
or account
Review Comment:
Hi @laurentgo and @singhpk234 - sorry to reopen this thread, but I think
there's another point worth bringing up on the ETag / caching side.
So far, even with StorageCredential, LoadTableResult has essentially been a
function of the table's commit state and the client identity. ReadRestrictions
adds a new axis of cardinality: they're evaluated per end-user subject that the
trusted client propagates, so the same table at the same commit now yields a
different response per subject.
We can keep this correct with the right `Vary` header like @laurentgo
suggested, but I'm concerned it also removes most of the client's ability to
reuse a cached loadTable response where one cached response used to serve all
the subjects behind a client, each subject now needs its own.
I'm beginning to wonder whether loadTable is the right endpoint for
ReadRestrictions, or whether a separate endpoint would be cleaner. I see value
in keeping loadTable strictly a client-identity dependent response, and letting
ReadRestrictions vary per subject on its own endpoint.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
