Workbench

Workbench

Issues Regarding Data Type Specifications in Domo Workbench

Member
edited March 5 in Workbench

We are experiencing the following issues with data type specifications when connecting data using Domo Workbench.

The attached image shows the results of our tests when connecting data to Domo via Workbench. The "number_DOUBLE" column is of DOUBLE type, and the "number_DECIMAL" column is of DECIMAL type. Please note that we are not using the LONG type as it results in errors.

Issues

  1. LONG Type: Handling numbers with more than 11 digits results in an error.
  2. DOUBLE Type: Handling numbers with more than 16 digits results in rounding, or the values beyond the 16th digit become incorrect.
  3. DECIMAL Type: Handling numbers with more than 15 digits results in empty values.

Could you please provide insights into the causes of these issues and possible solutions? Additionally, are these limitations due to the specifications of the system?

Note: The "number"column in the attached image represents the values that should be displayed in Domo.

image.png
Tagged:

Best Answer

  • Member
    Answer ✓

    What you're experiencing isn't inherently Domo Workbench, but rather how the data is stored in Domo's data warehouse. It seems that the number exceeds the maximum precision for that data type (ie. integers, floating-point numbers). Domo's interface and some of its processing might involve JavaScript; JavaScript uses a double-precision 64-bit binary format to represent numbers. For example, I replicated this using Domo Webform; the integer data type begins to round precision at row 17 (this indicates there's a 16 digit of precision limit via the GUI). Moreover, when I export this via CSV and view it an IDE I can see that the digit precision stored in the "number" field retains its precision. So, there may be limitations to digit precision for Workbench and the GUI (what you see on screen).

    example.png

Answers

  • Member
    Answer ✓

    What you're experiencing isn't inherently Domo Workbench, but rather how the data is stored in Domo's data warehouse. It seems that the number exceeds the maximum precision for that data type (ie. integers, floating-point numbers). Domo's interface and some of its processing might involve JavaScript; JavaScript uses a double-precision 64-bit binary format to represent numbers. For example, I replicated this using Domo Webform; the integer data type begins to round precision at row 17 (this indicates there's a 16 digit of precision limit via the GUI). Moreover, when I export this via CSV and view it an IDE I can see that the digit precision stored in the "number" field retains its precision. So, there may be limitations to digit precision for Workbench and the GUI (what you see on screen).

    example.png
  • Member

    Sorry for the delayed response. Thank you for the detailed explanation and answer! I also understand that the issue is related to the data types stored in Domo's data warehouse and the limitations of JavaScript's double-precision format. It seems that, due to these specifications, we'll likely end up having to convert the data type from a numeric type to a string type for numbers beyond the verified digit limit, doesn't it?

Welcome!

It looks like you're new here. Members get access to exclusive content, events, rewards, and more. Sign in or register to get started.
Sign In