cancel
Showing results for 
Search instead for 
Did you mean: 
Generative AI
Explore discussions on generative artificial intelligence techniques and applications within the Databricks Community. Share ideas, challenges, and breakthroughs in this cutting-edge field.
cancel
Showing results for 
Search instead for 
Did you mean: 

Querying Metric Views via Classic/Pro SQL Warehouses

Ankitkalra40
New Contributor II

I recently came across a unique edge case where I was serving a few metric views to my Genie Space.

Within metric views, I had custom formatting options such as currency in INR. 

When I was querying using a Serverless Warehouse, the results were correctly portrayed but upon switching to Classic/Pro the numbers were coming in international formatting with dollar symbols.

I believe this metric view option is not available for Classic/Pro warehouses just yet but need supporting evidence to convince the wider team of this observation.

Is there any metric view documentation or blog post available that calls out this limitation?

Also, does anyone know if this is something Databricks Product Team is working on in the future releases?

Thanks in advance.      

1 ACCEPTED SOLUTION

Accepted Solutions

Ashwin_DSA
Databricks Employee
Databricks Employee

Hi @Ankitkalra40,

Thanks for raising this. From what I can tell, this appears to be a known limitation rather than an issue with your metric view. The public docs confirm that metric views support formatting metadata, but they do not explicitly spell out this warehouse-specific difference. For example, the metric views overview says metric views can carry formatting rules, the YAML reference documents format on fields and measures, and the query metric views docs explain that formatting metadata is surfaced in downstream UI experiences.

So the formatting in metric views is a documented capability, but behaviour can still vary across surfaces and compute paths. Based on that, it is reasonable to say that the Classic/Pro versus Serverless difference is a current limitation, not a problem with your metric view definition itself.

On the product side, this appears to be an active area of work, but I do not yet have a public ETA or release commitment I can point to. If this behaviour is important for your use case, the best next step would be to share that feedback through your Databricks account team or support channel so that demand can be attached to the existing work.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***

View solution in original post

2 REPLIES 2

Ashwin_DSA
Databricks Employee
Databricks Employee

Hi @Ankitkalra40,

Thanks for raising this. From what I can tell, this appears to be a known limitation rather than an issue with your metric view. The public docs confirm that metric views support formatting metadata, but they do not explicitly spell out this warehouse-specific difference. For example, the metric views overview says metric views can carry formatting rules, the YAML reference documents format on fields and measures, and the query metric views docs explain that formatting metadata is surfaced in downstream UI experiences.

So the formatting in metric views is a documented capability, but behaviour can still vary across surfaces and compute paths. Based on that, it is reasonable to say that the Classic/Pro versus Serverless difference is a current limitation, not a problem with your metric view definition itself.

On the product side, this appears to be an active area of work, but I do not yet have a public ETA or release commitment I can point to. If this behaviour is important for your use case, the best next step would be to share that feedback through your Databricks account team or support channel so that demand can be attached to the existing work.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***

balajij8
Contributor III

You can handle the localization directly in the SQL model using CONCAT('INR', FORMAT_NUMBER(revenue, 2)) if you must stay on Pro. Otherwise, as Databricks recommends Serverless for optimal Genie Space performance, move to a Serverless SQL warehouse as it resolves it seamlessly