Print dev schema names when updating dev

[foundinblank]

If I do a sqlmesh plan dev this is the output I see:

Apply - Backfill Tables [y/n]: y
      analytics.seed_orders ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 1/1 • 0:00:02
analytics.incremental_model ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 1/1 • 0:00:04
       analytics.full_model ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 1/1 • 0:00:07

All model batches have been executed successfully

Virtually Updating 'dev' ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 0:00:01

It's somewhat counter-intuitive that if I go into my database, it's actually analytics__dev.* that will reflect the changes I've just made, while analytics.* haven't been touched. I think for clarity, if it's updating a non-prod environment, then the schema name shown should reflect that. It's also a more visible signal that someone is working within a different environment.

In other words, the output should be:

Apply - Backfill Tables [y/n]: y
      analytics__dev.seed_orders ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 1/1 • 0:00:02
analytics__dev.incremental_model ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 1/1 • 0:00:04
       analytics__dev.full_model ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 1/1 • 0:00:07

All model batches have been executed successfully

Virtually Updating 'dev' ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 0:00:01

[eakmanrq]

Great suggestion! Resolving now.

[tobymao]

Hey @foundinblank. This is a nuance to how SQLMesh implements environments.

When you're backfilling tables, there are no environments, tables are just physical locations that are environment agnostic. And so the UI shows the model name, which happens to match the name of the production physical view. So it is indeed confusing with how the current UI is represented.

What do you think about showing the actual physical location that's being backfilled. So for example, instead of analytics.seed_orders, we show, sqlmesh.analytics__seed_orders_1234123. this physical table would be queryable, but it's not something that we commonly expose to the user.

in terms of the virtually updating section, do you want to show all the views that were updated? this could be quite large, so we're not super inclined to do it.

we're trying to figure out a solution that is both intuitive and doesn't stray too far from the underlying implementation.

[tobymao]

@foundinblank, we've decided to go with your solution. we think that it will be the most intuitive flow and also conform to governance standards as we support more of that.

[foundinblank]

Hey there - thanks for considering this change! I completely empathize with the tricky balance between showing users exactly what's happening under the hood (the actual physical location) -- versus abstracting away the details and showing users what's happening from their perspective.

I think you made the right call here. Because with sqlmesh I think the aim is not to have users think too much about the underlying snapshots and variants. Instead, the aim is to cultivate an "it just works" vibe where users confidently know they're making changes that only affect their env and no other envs -- communicating the view name to them helps build that vibe.

I'll continue dropping UI suggestions here and there as I keep trying out sqlmesh, it's great stuff :)