Tables and publications

A table gives your project a stable way to identify a dataset. Its data can change after ingestion, a sync, or a transform run. Before comparing values or using them in code, identify both the table and the output you are inspecting.

Find a tableCopy Anchor Link

Your coding agent can list the project's tables:

vortexify tables
vortexify tables --name shop.orders --json

The list reports table IDs, source types, data status, and knowledge graph progress. Use an explicit ID if names are ambiguous. Uploaded tables, sync outputs, transform outputs, and database tables share the project inventory but have different execution behavior.

Open a table's details with:

vortexify table TABLE_ID --json

For published file-backed data, details include its schema, publication, producer version/job, and analysis progress. This command inspects metadata; use SQL analysis to read a bounded result from the CLI, or the platform Data view to browse rows.

Choose the output you meanCopy Anchor Link

For uploads, syncs, and transforms, a successful run publishes files and schema information. Each completed producer job retains its own output reference.

vortexify table TABLE_ID --deployed --json
vortexify table TABLE_ID --job PRODUCER_JOB_ID --json

--deployed and --job are mutually exclusive. The selected job must be a successful, fully published run of that table's producer. An arbitrary analysis job is not a table producer.

A source commit creates a version; it does not produce new rows. A failed newer run can leave an older successful publication readable. Check the publication's producer version and run when assessing freshness. Deploying a new producer version also needs a successful output for consumers of that version.

Browse in the platformCopy Anchor Link

Open a table directly from the project, or through its source resource's Tables view. File-backed tables let you choose Preview runs or Deployed version, then a published run. Choosing an older run pins that selection; later runs do not silently replace it.

• Data browses rows with filters, sorting, and pagination.
• Schema shows the selected publication's column metadata.
• Relationships shows its key findings, relationship evaluations, and analysis status.

A run's Output view can open the same table pinned to that run. This is useful when comparing an app's value to the output that produced it.

Platform screenshot placeholder: A table with Preview runs/Deployed version selection, a specific run selected, and Data/Schema/Relationships tabs. Keep the producer version visible.

Managed database tablesCopy Anchor Link

A database table represents live records in its provisioned environment. Its environment label matters; it is not selected by a sync/transform producer job. Use the database's Tables view to inspect those records and database migrations to understand how their schema changes.

Remove an uploaded datasetCopy Anchor Link

vortexify tables delete TABLE_ID soft-deletes an uploaded table. It does not drop a managed database table or delete the source data behind a connector. Check dependencies before removing a table used by another resource.

Continue with SQL analysis or keys and relationships.

Use an uploaded table in PythonCopy Anchor Link

After vortexify upload table customers.csv --name customers --wait succeeds, declare Table("_upload.customers") in transform/API inputs or agent context. _upload is reserved and cannot name a connector. This selects the existing uploaded table and its published Parquet data; no mock connector or sync is needed. Use actual table names and inspect the inventory if a name is ambiguous.