Catalog

Views

Name: Nexoxa Bridge
Author: Nexoxa

Standard views with definitions and dependents.

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.

Debugging a report that uses reporting.active_users, opens Views, reads the view SQL and owner, checks dependents — no guessing which ORM model mapped wrong.

The Catalog panel Views 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 Views from the left sidebar after you connect; everything here reflects the live connection, not a cached export from yesterday.

Bridge path: /database/views

Step 1

Definitions and owners

View SQL shows the extra JOIN that doubles counts. Owner reveals which service account to ping.
Dependents list shows downstream mat views.

Standard views with definitions and dependents. /database/views. Standard views with definitions.

Step 2

Fix in Query lab

Copy view SQL to lab, patch JOIN, test, open PR to replace definition.
One window workflow.

Export definition to Query lab. Schema-qualified names preserved.

Step 3

Link to materialized views

Dependent mat view stale — navigate to Mat. views panel from dependency link.
Catalog panels chain naturally.

Dependents surfaced in metadata introspection.

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