apache
Materialized View Spec
This PR implements the Iceberg Materialized View Proposal #10043 by adding a section for Materialized Views to the View spec. It follows the design of the proposal document.
The idea is to resolve any remaining questions before starting the voting process on the dev list.
CC @rdblue @danielcweeks @RussellSpitzer @szehon-ho @wmoustafa @jackye1995 @emkornfield @findepi @stevenzwu
This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the [email protected] list. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.
When materialized view is created, two entities would be added to the catalog - a view and a storage table. From the engine perspective it is important to expose it as a single object during listing. Are there any rules how catalog implementors should deal with these objects? E.g., shall we expose the view via listViews, but filter-out the storage table for listTables?
Yes correct, the idea is to filter-out the storage-table for the listTables operation. But I would regard this as not part of the table/view spec but should rather be included in the REST catalog specification.
If i understand correctly @wmoustafa comment on the mailing list, then there is some ambiguity here for what to put, if the same table in expressed in the various forms (catalog.database.name) or (database.name) or (name), either in same sql statement or in the different sql representations of the same view.
I am still -1 on this change before resolving https://github.com/apache/iceberg/pull/11365. Further, I am also -1 on referencing table identifiers in table snapshot summary. We had extended discussions on this and converged at some point already.
If i understand correctly @wmoustafa comment on the mailing list, then there is some ambiguity here for what to put, if the same table in expressed in the various forms (catalog.database.name) or (database.name) or (name), either in same sql statement or in the different sql representations of the same view.
I am still -1 on this change before resolving #11365. Further, I am also -1 on referencing table identifiers in table snapshot summary. We had extended discussions on this and converged at some point already.
This is from the discussion in https://lists.apache.org/thread/v8m1tpb91g740gmvqyphhjw37mpr8sl7 right? if i understand the discussion, it is good to clarify the existing assumptions that allow portability of all views (not just MV), I'm also +1 on adding the idea of #11365, but it seems most opinions there was that it should not block MV spec.
If i understand correctly @wmoustafa comment on the mailing list, then there is some ambiguity here for what to put, if the same table in expressed in the various forms (catalog.database.name) or (database.name) or (name), either in same sql statement or in the different sql representations of the same view.
I am still -1 on this change before resolving #11365. Further, I am also -1 on referencing table identifiers in table snapshot summary. We had extended discussions on this and converged at some point already.
This is from the discussion in https://lists.apache.org/thread/v8m1tpb91g740gmvqyphhjw37mpr8sl7 right? if i understand the discussion, it is good to clarify the existing assumptions that allow portability of all views (not just MV), I'm also +1 on adding the idea of #11365, but it seems most opinions there was that it should not block MV spec.
I think it should block, but in all cases, we should have a mailing list vote on this spec anyways. That way it becomes formal. Happy to continue the discussion before voting to align.
This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the [email protected] list. Thank you for your contributions.
This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.