Export Questions and Dashboards to different instances


Is there a way to extract Questions and DAshboards from one server and to reload to another server with the same database structure (but not the same data), for instance for different installations of the same database (but with different set of data) ?

You can do it with SQL. Difficult bit is promoting changes from one to another.
The SQL bit is on my list of things to do, I just need to find a customer to pay for it!

Sorry @AndrewMBaines (for ruining your paid job plan - though I’m sure there will be even better opportunities with this as part of the package :smile: – and I’d imagine there’s room for building onto this and maintaining it as the Metabase schema evolves going forward).

Just 4 hours ago it seems @mausch just beat you to the finish line with what sound exactly like what should fit with @ComputingFroggy’s scenario - although it’s built as a C# code using the Metabase API. See this “announcement” comment on GitHub:

Full disclaimer: I haven’t taken it for a spin myself … yet … but it looks promising. :clap: :clap: to @mausch for sharing :tada:

Will be interesting to see how it copes with the lack of a unique id across installations. Good news though.

At the moment, I have a db for each customer and just copy back and forward.

Good point :+1: global unique ids certainly would be a nice addition. I think you already posted to a topic somewhere here on that :slight_smile:

Not sure if this is what you mean by “unique ids across installations” but this tool deletes existing questions/dashboards and creates new ones when restoring from file, which means that IDs keep growing and growing.
In my app code I look up Metabase entities for embedding by name not by ID to work around this.

My unique ID point is where you want to have a test and live instance with the live instance being updated from test.
For example, I design Dashboard 1 in test. Publishing to live is easy as it doesn’t exist yet.
Next, I update Dashboard 1 in test. I want to update it in live, but there is nothing unique to link the source and destination.

I’m used to working with SAP BI. In that, every object has an ID within the server, but also has an additional GUID that is unique to that object. If you migrate from server A to B, the ID will change, but the GUID will remain the same. Means you can always identify the source.

With your method of just incrementing the ID, when I come to update a question, I’ll not be able to update the original question in the destination server. I just get 2 similar questions.

How do you manage the database ID?

When this tool imports from a file to a Metabase instance it deletes everything first, so you won’t get two similar questions.

With your method of just incrementing the ID

Just to be clear, my tool does not increment the IDs. It’s a consequence of Metabase defining autoincrement IDs in its database schema.

How do you manage the database ID?

Database IDs are mapped externally at import-time i.e. the user running the import command has to know what database IDs on the target Metabase instance correspond to the database IDs in the backup file.
Mapping mismatches are checked when starting the import process so if there are missing mappings the import process errors out.
See https://github.com/elevate/elevate.metabase.tools#import for an example.

I see, so it’s replacing everything, I didn’t appreciate that.
What I want to do is create a package of questions and dashboards that could be added to an existing installation, or update the existing contents non-destructively.

I see… I agree that would need that stable ID like you said, or assume that question/dashboard names are stable (kinda risky)

It’s frustrating - all it would take would be some form of ‘bucket’ we could throw key-value pairs into. I looked into using just SQL to move stuff around, but that’s dangerous with version changes.
I think the only other option without wholesale application changes would be some sort of helper table.

I think the import-merge feature mapping by item name could be useful. Just created an issue about it on the github repo in case anyone is interested in working on it: https://github.com/elevate/elevate.metabase.tools/issues/8