Skip to content

Salesforce converter: translate OSI metric expressions and validate field references #403

Description

@saurabhdeshp

#402 adds metric export but leaves expression translation and field-reference validation for follow-up work. This issue covers that work, including the reference validation requested in #399.

The goal is to convert supported SQL expressions into Tableau formulas so users can reuse their OSI metric definitions without maintaining a separate Tableau expression for each metric.

Initial scope

  • Aggregates: SUM, AVG, MIN, MAX, COUNT(field) and COUNT(DISTINCT field).
  • Arithmetic: +, -, *, /, parentheses and numeric constants.
  • Conditional logic: CASE WHEN, comparisons, AND, OR and NOT.
  • Null handling: COALESCE, NULLIF, IS NULL and IS NOT NULL.
  • Numeric functions: ABS, ROUND, CEIL and FLOOR.

Support combinations of these functions, including expressions such as:

SUM(orders.amount * (1 - orders.discount))

SUM(CASE WHEN orders.status = 'paid'
         THEN orders.amount ELSE 0 END)

SUM(orders.profit) / NULLIF(SUM(orders.revenue), 0)

Expected behavior

  • Translate supported SNOWFLAKE and ANSI_SQL expressions into Tableau syntax.
  • Resolve references against declared datasets and fields, including quoted identifiers.
  • Validate types and aggregation rules while preserving the original calculation’s meaning.
  • Fail with the metric name and a clear explanation for unsupported expressions, missing fields or ambiguous references.
  • Test combinations, nulls, empty inputs, duplicates and zero denominators. Validate results in Tableau Next alongside unit and schema tests.

Date/time functions, string functions, casts, references to other metrics, window calculations and level-of-detail calculations can follow as separate milestones. COUNT(*) also needs separate handling to establish which dataset’s rows are being counted.

Source-object discovery, missing-field enrichment and deployment are outside this issue. The extension-preservation fixes identified in #402 should remain there.

i’ll take this on through follow-up PRs built on #402. The implementation should align with the expression-language work in #222.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions