[Models] Don’t rerun the query when entering edit mode if there are results

[gusaiani]

If the user clicks to edit a model definition after the model returned results, we should use the returned results and not run the query again.

The same applies if the user changes from Edit query to Edit metadata mode.

For more context, see https://www.notion.so/metabase/Make-model-editing-faster-and-easier-ee31edef605c486e8f9c0fbe70fa3af2

[gusaiani]

Anton's comment:

This might get tricky. When entering/leaving the model editor, the query gets refreshed for a reason.

This happens because for Metabase a query you see on /model/1 and /model/1/query pages are different.

For /model/1 you’re working with a query that is source-table: "card__1", where card__1 is our model.

On the other hand, for /model/1/query we need the actual model query (with SQL or original MBQL).

I’ve explained it in a bit more detail in this PR (see “Out-of-sync metadata” section). This comment also explains the idea

Maybe it’d be enough to just reload metadata, but I’m not sure

[daltojohnso]

Questions are now cached in the god-metadata object and can be accessed via the question method -- metadata.question(cardId) => Question. This might make this issue simpler to deal with. You will need to add some logic to the QB to recognize that going from card__1 to the underlying query of card 1 doesn't need a rerun.

[gusaiani]

More notes on this from Anton:

/model/:id route is similar to what you get when you open a table in the query builder. You start with a blank question only having source-table: in its dataset_query. This lets you extend the query and eventually save it as a new question. This model route acts in a similar way: we open a question with source-table: card__$MODEL_ID. Kinda like when you’re building a question on top of another question. This lets us build a new question on top of the model without too much hassle. Since it’s an ad-hoc question, we’re using /api/dataset to actually query data.

/model/:id/query is a bit different as we want to work with the underlying model query rather than build something on top of it. So instead of source-table: card__$MODEL_ID we’re using the full query. This lets us modify the model query and populate the changes in all the questions using that model (as they’re just referencing them via card__$ID). In this case we use /api/card/:id/query to query data.

There’s a difference about result_metadata shape in those cases. When we’re working with the full query in the model query editor, we get the full info about the origin of fields (for instance, fields coming from a joined table have join-alias in their field reference; custom columns are explicitly defined like [ "expression", "field_name", … ]). On the other hand, when we’re in “new ad-hoc question based on model” mode at /model/:id page, the underlying query is more of a blackbox, so join-aliases are hidden, expression fields are looking like regular fields ( [ "field", "name", … ])

So you can try creating an MBQL model with joins and custom column and see the differences. You can also try removing the “rerun query” logic for models to see what exactly blows up