steveloughran commented on PR #15111: URL: https://github.com/apache/iceberg/pull/15111#issuecomment-3926781777
@rdblue thanks, I think I've been looking at schemas too often and my brain is confused there. To be ruthless, the merits of supporting Trash in iceberg is something to consider. It matters in Hive to stop DROP TABLE calls, but even in hive I'm not confident that if you do a job which updates a table, the previous contents of that table can be recovered. iceberg time travel lets you go back to all previous states of a table up to the previous compaction, so all trash and trash recovery would do is * let you go to before the last compaction date with content now decoupled from the table * recover from `dropTable()`, whose spec already says "without requesting that files are immediately deleted." * recover from `purgeTable()` It seems to me that having the catalog implementations explicitly preserve dropped tables for a period of time would be better than having the lower layers try to do something similar on a file-by-file basis, especially as that would then work everywhere -- 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]
