Improve API of view catalog object

[leiysky]

So far, if we want to get the query text of an exists view, we have to:

• Get a Table object from Catalog with Catalog::get_table
• Check if it is a view object by validating Table::engine() == "VIEW" (even case-sensitive)
• If it is a view object, then there is a deterministic key-value pair in Table::options(), which is "query" -> query_text. Thus we need to get the query text with Table::options().get("query").unwrap().

IMO, it's an anti-intuitive API design. Since view object is a very common data source object in database, it deserve a well-typed structure.

I propose to introduce a data source API like:

struct View {
    pub view_name: Vec<String>,
    pub query_text: String,
}

pub enum DataSource {
    Table(Arc<dyn Table>),
    TableFunction(Arc<dyn TableFunction>),
    View(View),
}

fn main() {
    let catalog = Catalog::new(); // whatever, just give a Catalog object
    let data_source = catalog.get_datasource(... /* Qualified table reference name */)?;
    match data_source {
        DataSource::Table(table) => // do sth with Table
        DataSource::TableFunction(table_func) => // do sth with TableFunction
        DataSource::View(view) => // do sth with View
    }
}

And also, it's better to make Engine a well-typed structure as well:

enum TableEngine {
    Fuse, // "FUSE"
    Github, // "GITHUB"
    Memory, // "MEMORY"
    Hive, // "HIVE"
    ... // Other static engine types

    Dynamic(String)
}

impl Display for TableEngine {...}

[leiysky]

cc @dantengsky @drmingdrmer

[drmingdrmer]

I love the idea of giving a dedicated type for every concept.

One question: there will be two more types that need to be serialized and stored in metasrv right? The TableEngine and View.

BTW why is the view_name a vec of String but not a single string? 🤔

[leiysky]

One question: there will be two more types that need to be serialized and stored in metasrv right? The TableEngine and View.

Not exactly. It can be a wrap of the script language style API(access everything with string) mentioned above. But I prefered not to treat Views as table engine.

BTW why is the view_name a vec of String but not a single string? 🤔

It's not necessary. I just want to say that it can be a qualified name.

[drmingdrmer]

One question: there will be two more types that need to be serialized and stored in metasrv right? The TableEngine and View.

Not exactly. It can be a wrap of the script language style API(access everything with string) mentioned above. But I prefered not to treat Views as table engine.

Got it.

[drmingdrmer]

Looks good to me

[leiysky]

Looks good to me

What's the plan 🤔 ?

[drmingdrmer]

IMHO:

• Add view related API to SchemaAPI.
• Catalog access SchemaAPI to fetch a view and build a DataSource::View for its caller.

But what I'm not very sure about is whether this new DataSource type is suitable for the current design of the databend-query.
Need suggestions:)
@BohuTANG

[BohuTANG]

By the way, Hive is not a table engine. It's catalog type, and I think @dantengsky may have more comments.