Hey I've been reading several questions regarding the possible workarounds for copying the same dashboard to several databases that share the same schema but have not been able to define a best possible usecase.
I want to try and create a dashboard to be replicated for several databases that all share the same schema but not the same data, the problem arises when trying to take advantage of several of metabase features, like models and filters. If i want to create a dashboard that can be linked with several filters for each question and autopopulate those filters with the values from the corresponding column i have only been able to do it with Models, but when duplicating a dashboard that uses Models you can't change the model of origin, even if you replace it with a model that shares those same attributes, without losing all the filtering, summarizing and ordering done in that question wich means you have to recreate the whole dashboard from scratch after creating all the models from the new database.
Is there any way (without using serialization) to be able to replicate a dashboard without having to recreate all the dashboards that I might be overlooking?
I've even tried using a database that aggregates all the other databases using trino but I have found no way to use a variable to determine what schema to take the data from to query the correct database. If there is any way to do this last part it would solve the modeling problem as I'd be able to create more complex dashboards that can be set up using only sql but changing from what database source you are selecting.
Does the new Database Routing feature in Metabase 55 not work for your case? It sounds like you are doing multitenant. Or is it more multi-environment, i.e. dev/stage/prod?
It might work but we are not using pro nor enterprise (that's why serialization would't work either)
What I'd love to know is if there is any way to either:
1)Create a question with another question as it's source in a dashboard that when I duplicate the dashboard it changes the source reference to the new duplicated source so i can alter that source.
2)Add a variable to work as part of the schema so i can use the same source questions but change via query parameters it's database with a trino data lake
2)Change from native sql to metabase's questions or change the database of origin of a question without losing all the filtering/summarizing of that questions. This would be a worse case scenario but would allow me to keep other features that questions provide more easily than doing each dashboard from scratch every time.
In SQL questions, you can reference models and other questions using variable-style replacement tokens.
I'd have to test it, and I don't know about Trino specifically (PostgreSQL guy here), but in SQL questions, the replacement tokens don't rely on any context, so you could have make table references like {{schema}}.tablename with schema attached to a text variable.
Changing the question type from SQL to Notebook is non-trivial. It's easy to write SQL that isn't representable in Notebook. Having the two question types are what make Metabase the flexible tool it is.
I haven't dug into Metabase's internal representation for databases yet (or the API for that matter), but I assume that things like tables and columns are individual objects, and things like summarizations and filters reference those internal objects. Changing the parent table invalidates all those references. Metabase simply doesn't know that even though table A and table B have columns of the same name that they work in exactly the same way and can be replaced as-is.
This sounds like a job for an external tool--one that can examine the references that make up a question, take a table name to migrate it to, figure out if they're compatible, and regenerate the question with the new table, fixing up the references along the way.