Computed Join FAQ

Answers to common questions about Computed Joins. Use the section closest to what you are working on.

Container Selection

Which containers can I pick in the Left and Right dropdowns?

Any profiled container in the datastore (tables, views, files), plus Computed Tables and Computed Files. Unprofiled containers do not appear; profile them first to use them as join inputs. See Supported Inputs.

Can I join containers from different datastores?

Yes. The Right Container dropdown can point to a different datastore. The Computed Join itself lives under the left container's datastore. You need at least Viewer permission on the right datastore to read its data and build the join. Reporter on the left datastore is enough to view the joined output once it exists, but not to use the right datastore as an input. See Permissions.

Can a Computed Join be the input of another Computed Join?

No. Computed Joins cannot be used as inputs to other Computed Joins. To combine three or more sources, materialize the first join's result as a Computed Table and use that Computed Table as one side of the next Computed Join. See Supported Inputs and Computed Tables.

Configuration and Validation

Why is the Left Datastore locked in the form?

The Left Datastore is the datastore you opened to create the Computed Join, so you always know which datastore owns the join. Only the Right Datastore can be selected, and it can point to a different datastore. After the Computed Join is saved, neither side can be changed.

What does the Select Expression auto-fill with?

When you select both containers, the Select Expression auto-fills with every top-level field from both sides, prefixed with the configured left and right prefixes. Trim it to the columns you actually need before saving. See How It Works.

What happens when I change a Prefix?

Changing a Prefix rewrites every matching column reference in the Select Expression automatically. If you hand-edited the Select Expression with the old prefix, those references are rewritten too. See Best Practices · Prefixes.

Can I edit the Left or Right Container after the join is created?

No. The Left Container and Right Container are immutable after creation. To change them, delete the Computed Join and create a new one.

Which join types are supported?

Inner, Left, Right, and Outer (Full Outer). Pick the type from the Join Type dropdown when creating or editing the join. See How It Works.

Why isn't DISTINCT allowed in the Select Expression?

The validator rejects every form of DISTINCT in the Select Expression: the bare DISTINCT keyword, DISTINCT(col), aggregate forms (COUNT(DISTINCT col), SUM(DISTINCT col), AVG(DISTINCT col), MIN(DISTINCT col), MAX(DISTINCT col)), APPROX_COUNT_DISTINCT(col), and multi-column variants. To deduplicate results, replace DISTINCT col with explode(collect_set(col)), adding a GROUP BY only when the Select Expression still has non-aggregated columns. See Best Practices for the full recipe.

What's the difference between Validate and Save?

Validate runs the configuration and reports parse or schema errors without saving. Save runs the same validation, then persists the join if validation passes. Validate is useful when iterating on the Select Expression or Filter Clause before saving. See Create a Computed Join and Edit a Computed Join.

Permissions

Who can create a Computed Join?

Users with Editor permission on the left datastore can create any Computed Join and can set the owner to any user. Users with Author permission can create Computed Joins they own; the owner is set to the user who creates the join, and only an Editor can reassign it later. In both cases, you also need at least Viewer permission on the right datastore. See API · Permissions.

Who can view a Computed Join?

Any user with at least Reporter permission on the datastore can view the Computed Join, its profile, and its anomalies. See API · Permissions.

Can an Author edit a Computed Join they don't own?

No. An Author can only edit Computed Joins they own. Editors can edit any Computed Join on the datastore. See API · Permissions.

Can an Author transfer ownership?

No. Only an Editor can reassign the owner of a Computed Join. See API · Permissions.

Execution

Can I run quality checks on a Computed Join?

Yes. A Computed Join supports the same quality checks as any other container. See How It Works.

Does a Computed Join count as a container?

Yes. The joined output appears under the left datastore's container list with its own profile, anomalies, checks, and scan history. See Introduction.

What happens to a Computed Join if I delete one of its input containers?

The delete is blocked and a confirmation dialog lists the Computed Joins that depend on the input. Delete the Computed Joins first, then the input. This applies whether the input is a table, view, file, or Computed Table. See Delete a Computed Join.

What happens to the join's profile and anomalies when I delete it?

They are removed with the Computed Join. The source containers and their data are untouched. See Delete a Computed Join.

What happens when the schema of an input container changes?

When you next save or profile the Computed Join, the platform 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 quality checks and anomalies are preserved until the fields reappear. See Edit a Computed Join and API.

Are Computed Joins incremental?

No. A Computed Join always reads both sides in full at execution. You can configure an Incremental Strategy and Incremental Field on the joined output so that downstream scans of the result process only new rows, but the join itself still reads both sides in full. See How It Works.

How do null keys behave?

Rows where either side of the join key is null are dropped 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. If you need standard SQL null-key behavior, pre-process each side as a Computed Table that fills null keys with a placeholder value. See How It Works.