Improved Error Mapping for Compiled SQL Errors

Report Bugs
1

Hi!

I am writing to provide feedback on a significant friction point regarding error handling within the Data Model “Data” tab.

When running a preview of a model with many columns, I frequently encounter generic errors such as:

“One of your Number Fields contains an unsupported value: ‘…’. Please review your Fields/Conditions/Formats…”

The Problem: The error message does not specify “which column” is triggering the failure. In a large model, this turns debugging into a “needle in a haystack” exercise, requiring me to add columns one by one to find the culprit.

Requested Solution: Could Holistics implement a way to map these execution errors back to the UI field name? Ideally, the error message should explicitly state: “Error in field: [Field Name].”

I would prefer to keep my aggregation logic within Holistics to leverage the semantic layer, but if debugging continues to be this cumbersome, I will be forced to move all complex logic upstream into dbt and use Holistics only as a thin visualization layer.

I hope this feedback is helpful and that improving error traceability is on your immediate roadmap.

3 Likes
2

Hi @pevso,

I understand your frustration - the current error messages get really hard to work with once the model has lots of columns.
Your suggested solution makes a lot of sense. I’m going to share it with our team and will follow up as soon as I have an update.

Also, could you share more about how you define the semantic layer within Holistics, the data warehouse you’re using, and a concrete example in one of your data models? With that, we can work on making the error output more actionable, or we may even get rid of the noisy errors completely.

1 Like