Skip to content

How Computed Join Works

A Computed Join is configured through a form and executed by Qualytics. The form captures what to join and how; Qualytics then loads each side, applies the join, and returns the projected result.

The Form

The Add Computed Join form's join-related fields are:

REF. Field Description
1 Name The unique name for your Computed Join container.
2 Join Type One of: Inner Join (keeps only matching rows from both sides), Left Join (all rows from the left container, matching rows from the right), Right Join (all rows from the right container, matching rows from the left), or Full Outer Join (all rows from both containers).
3 Left Reference The left container, including its parent Datastore, the Container itself, the Field to join on, and an optional Prefix (defaults to left) applied to all columns from this container.
4 Right Reference Mirrors Left Reference (Datastore, Container, Field, Prefix). The Prefix defaults to right, and the right container can live in a different datastore.
5 Select Expression A SQL select clause naming the columns to include in the result, with optional aliases and expressions. Columns are automatically prefixed (for example, left_name, right_name) to avoid name collisions. When you select both containers in create mode, the Select Expression auto-fills with every top-level field from both sides.
6 Filter Clause (WHERE) Optional filter applied to the joined result. Must be a valid SQL predicate.
7 Group By Clause (GROUP BY) Optional grouping when using aggregate functions (COUNT, SUM, AVG, MIN, MAX, and similar) in the Select Expression. All non-aggregated fields in the Select Expression must also appear in the Group By Clause.

Execution Flow

Qualytics runs the join during profile and scan operations, and during the synchronous validation step when you click Validate or Save. On every run, Qualytics loads each side independently and computes the join:

  1. Load the left container from its source datastore.
  2. Load the right container from its source datastore.
  3. Compute the join using the chosen join type and the configured join fields.
  4. Apply the Select Expression to project the columns named in the clause.
  5. Apply the Filter Clause (post-join WHERE) to the projected result.
  6. Apply the Group By Clause if grouping is configured.
  7. Return the final result as the Computed Join's output.

Qualytics does not store the joined rows. Each profile or scan re-loads both sides and recomputes the joined result, so the output stays in sync with the underlying containers without a manual refresh step.

Cross-Datastore Joins

The left and right containers can live in different datastores (for example, a JDBC table joined with a DFS file). Qualytics loads each side from its own datastore and computes the join. Throughput is bounded by the slower side; to reduce what each side loads, materialize a filtered Computed Table or Computed File and use it as the input.

The Computed Join itself lives under the left container's datastore. To create a cross-datastore join, you need at least Viewer permission on the right datastore.

Null Keys

The join drops rows where either side of the join key is null before matching, regardless of join type. A null on the left does not match a null on the right. This differs from standard SQL for Left, Right, and Outer joins, which would preserve unmatched rows. To preserve unmatched null-keyed rows, materialize each side as a Computed Table or Computed File that replaces null keys with a placeholder value.

Output Behavior

The joined output behaves like a regular container in Qualytics:

  • It appears in the left datastore's container list.
  • It has its own profile. A fresh profile runs on every save, with deeper re-profiling triggered when the fields produced by the join change. A profile also runs on the next scan or profile you trigger.
  • It supports observability features (volumetric tracking, freshness checks).
  • Quality checks can run against the joined result.

Computed Joins are not partitioned. Scans and observability work against the full joined result.

Sync and Computed Joins

Sync discovers containers from the source system. A Computed Join is produced by Qualytics rather than discovered, so Sync's Inaccessible, Unloadable, and Prune rules do not apply to it.

Field Changes on Inputs

When the Select Expression no longer produces a field that has active quality checks or anomalies, the next save or profile lists the dropped fields. Confirm Proceed Anyway in the UI (or set force_drop_fields=true in the API request) to apply the change. The dropped fields are marked missing, and their attached quality checks and anomalies are preserved until the fields reappear in a future edit. See Removed fields warning on Save for the message format and recovery steps.

Permissions

Creating, editing, or deleting a Computed Join requires:

  • Editor on the left datastore, or Author on the left datastore plus ownership of the Computed Join.
  • At least Viewer on the right datastore (when the right container lives in a different datastore).

Reading the joined output requires at least Reporter on the datastore. Only an Editor can reassign the owner to another user; Authors cannot transfer ownership.