jackye1995 commented on issue #6420: URL: https://github.com/apache/iceberg/issues/6420#issuecomment-1426852565
I think it has to be a catalog-specific decision, because as you said Snowflake has that hidden, but for example Trino view on Hive/Glue has the storage table exposed. So I am not sure if it needs to be a part of the spec or not. I think these are different type of catalogs, typically we distinguish them as **business data catalog** and **technical data catalog**. The former is more oriented for end user, whereas the later is more oriented to technical users that would like to see all the hidden stuffs. From implementation perspective, why does approach 2 need "definition of commit procedure"? I think it's just a matter of hide the storage table or not, but there will always be 2 objects behind the scene. If you are talking about committing changes to both objects at the same time, @nastra is already doing a proposal of multi-table transaction, so I think that problem will be solved there and we don't need to worry in the MV spec. -- 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
