Catalog

Foreign keys

Name: Nexoxa Bridge
Author: Nexoxa

FK constraints with ON UPDATE/DELETE rules.

The story

These pages use illustrative scenarios to walk through real workbench panels. Sidebar labels, Bridge paths, and connection schemes match the app; characters and timelines are examples for learning.

Planning ON DELETE CASCADE change, opens Foreign keys — every constraint with update/delete rules — and traces parent/child in Knowledge graph.

The Catalog panel Foreign keys is where Bridge turns raw metadata into decisions — counts, definitions, dependencies, and links into the grid or Query lab. No information_schema archaeology; no guessing which mat view is stale.

Open Foreign keys from the left sidebar after you connect; everything here reflects the live connection, not a cached export from yesterday.

Bridge path: /database/foreign-keys

Step 1

ON UPDATE / ON DELETE rules

orders.client_id CASCADE — dropping client row nukes orders. Change to RESTRICT?
Rules visible without pg_constraint query.

FK constraints with ON UPDATE/DELETE rules. /database/foreign-keys. Full FK metadata.

Step 2

Navigate parent and child

Click parent table → grid. Click child → grid. Migration impact obvious.
Graph view for big picture.

Navigation to Tables and Data grid. Knowledge graph for communities.

Step 3

Migration order

Copilot and graph agree: touch clients last. FK panel is source of truth.
Safer Friday deploys.

Feeds db-knowledge-out FK communities.

This panel appears in the Nexoxa Bridge left sidebar after you connect with the matching connection URL. See the connection docs above for postgresql://, ssh://, sftp://, s3://, or smtp:// examples.

Related connections

Database connection URLs