OK, then I'd vote for TableViewCatalog, because 1. This is how Hive catalog works, and we need to migrate Hive catalog to the v2 API sooner or later. 2. Because of 1, TableViewCatalog is easy to support in the current table/view resolution framework. 3. It's better to avoid name conflicts between table and views at the API level, instead of relying on the catalog implementation. 4. Caching invalidation is always a tricky problem.
On Tue, May 25, 2021 at 3:09 AM Ryan Blue <rb...@netflix.com.invalid> wrote: > I don't think that it makes sense to discuss a different approach in the > PR rather than in the vote. Let's discuss this now since that's the purpose > of an SPIP. > > On Mon, May 24, 2021 at 11:22 AM John Zhuge <jzh...@apache.org> wrote: > >> Hi everyone, I’d like to start a vote for the ViewCatalog design proposal >> (SPIP). >> >> The proposal is to add a ViewCatalog interface that can be used to load, >> create, alter, and drop views in DataSourceV2. >> >> The full SPIP doc is here: >> https://docs.google.com/document/d/1XOxFtloiMuW24iqJ-zJnDzHl2KMxipTjJoxleJFz66A/edit?usp=sharing >> >> Please vote on the SPIP in the next 72 hours. Once it is approved, I’ll >> update the PR for review. >> >> [ ] +1: Accept the proposal as an official SPIP >> [ ] +0 >> [ ] -1: I don’t think this is a good idea because … >> > > > -- > Ryan Blue > Software Engineer > Netflix >
