singhpk234 commented on PR #14502:
URL: https://github.com/apache/iceberg/pull/14502#issuecomment-3782182589

   > If you detect this, you can also remove the stats on the server side. That 
may look similar to what is here, but I think that it is better to have limited 
code in the service for this rather than introduce something in the library. We 
don't want people using this to edit old snapshots, which are effectively 
immutable right now. Introducing this would change that guarantee.
   
   I thought about it a lot, i think fair to not include this in the library 
then, `TableMetadataProjection` would have circumvented this interpretation but 
i think the boundary becomes blurred since this is only what server see for the 
client its still is the immutable TableMetadata. i think for new snapshot when 
we know the table is protected we can just planinly reject it and ask the 
customer to fix and fail in runtime if we detect any snapshot has partition 
summary and table is protected, prompting the customer to fix / expire the 
snapshot (not sure if they would be open to it). All i think i got the stand 
point that we don't wanna be opinionated on the catalog behaviour and from 
library POV we work under assumption of the TableMetadata being assumption. I 
will think this more if i can get something generic enough in context of 
protected tables so we have some spec language. Thank you for the feedbacks 
here @rdblue @amogh-jahagirdar 
   
   > if you're using something like Jackson, when serializing responses it's 
possible to specify a TokenFilter in the mapper write
   
   Definitely, I think may be i should i just write a serializer and register 
that in my jackson `toJson` to strip out snapshots.
   
   while we do this do we think its valuable to remove writing partition 
summary from sdk now that we have partition stats ? 
`write.summary.partition-limit` from 
https://iceberg.apache.org/docs/nightly/configuration/#write-properties ? 
   
   


-- 
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]

Reply via email to