JanKaul commented on issue #55: URL: https://github.com/apache/iceberg-rust/issues/55#issuecomment-1702457582
> Hi, @JanKaul Good point for view. Except for view, I think there will be other entities like [materialized view](https://github.com/apache/iceberg/issues/6420). So the question is about name resolution: > > 1. Should we keep separate method for resolving tables, views, event materialized view? > > > ```rust > fn load_table(&self, table_name: TableId) -> Result<Table>; > fn load_view(&self, view_name: ViewId) -> Result<View>; > ``` > > I think it's still useful to keep separate methods for each kind of entity. For example when I want to execute dml like: > > ``` > insert into t values(1), (2) > ``` > > The query engine knows that it should load a table to check it. > > 2. Should we have a method for resolving entities without knowing its entity type? > > > As @JanKaul said it's would be quite useful in query: > > ```sql > select * from t; > ``` > > In this case the catalog api should provide sth like: > > ```rust > fn load_entity(&self, table: &TableId) -> Result<TableLike> > ``` > > 3. Should we keep both methods or just `load_entity`? > > > Keep `load_entity` method only can solve problem in 1. But I still want to keep methods in 1 for several reasons: > > * The api is more user friendly. > > * This gives concrete implementation more chances to do optimization, especially in cases where many tables and views are defined. Good points, @liurenjie1024. I think it would make sense to have `load_table`, `load_view` and `load_entity`. Just that for `SELECT` queries it would be good to use `load_entity`. For cases where the query engine knows whether it's a table or a view it can call `load_table` and `load_view`. -- 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]
