Change the name of the generated trino tables about metriql HOT 3 OPEN

In dbt, the models and sources are not unique so we had to have these prefixes to avoid name collisions. However; we support dbt references so you can access them as follows:

select count(*) from "ref('orders')" 

or:

select count(*) from "source('tpch', 'orders')" 

Which tool are you using to access Metriql datasets? Maybe we should expose the sources as dbt references, not internal names?

from metriql.

That is true. I explored it a bit with DBeaver now and it doesn't feel super nice with the naming convention currently popping up :) For eg. we only expose a virtual mart to metriql, or for that case all the places actually consuming data, so sources are never exposed outside of DBT. It wouldn't be possible to just give a naming convention for sources so it turns out to be tpch_orders? I feel there must be some sweet solution :)

One more reason is if there is no "automation" ready for a BI Tool, the models(or whatever it's called in each BI Tool) will have really weird names for the end user, instead of actually just showing them what they are looking for.

from metriql.

@AndreasTA-AW actually, we don't expose these names to the BI tools. We use dataset.label instead of the internal unique id of the datasets. You can override the label in the YML file but the default is the model name as you suggested.

You only see the internal names when you run commands like SHOW TABLES in a SQL client such as DBeaver. In addition to that, you should access the dataset using the dbt references as I mentioned in my previous message but I agree that it's not convenient to see these internal names even in your SQL client because they're not helpful in terms of navigating the datasets.

What's your suggestion in this case? Should we expose the dbt references such as source('tpch', 'orders') instead of internal names such as project_name_tpch_orders? In that case, the models will be exposed as ref('project_name', 'orders') to avoid name collisions.

The reason why we had to expose the internal names was primarily that the special characters such as ( feels anti-pattern and people might find them confusing but we're always open for feedbacks.

from metriql.