Drop a table

drop_table permanently deletes a table - all its data and Delta-log files. It is irreversible: there is no undo, and no time-travel, rollback, or restore afterward (the log they'd need is gone).

Drop

eddytor delete table eddytor sales orders

DELETE /v1/tables/eddytor/sales/orders
Authorization: Bearer edd_live_…

drop_table(table="eddytor.cfg_xxx.<uuid>_orders", confirm=true)

Safety guards

Alternatives - when you don't actually want it gone

• Reorganising? Rename or move instead - both keep the data.
• Want a copy first? A final query_rows / Flight SQL read, or download the objects, before dropping.
• Just clearing rows? Delete rows keeps the table (and stays recoverable until vacuum).

Blocked drops

drop_table (and rename / move) is refused while another table references this one through a cross-table reference domain. The reference is a live foreign-key-style link, so Eddytor won't let you pull the source out from under it: a reference domain on table B points its column at a column in table A, and dropping (or renaming/moving) A would orphan B's constraint. There is no force flag.

To unblock it:

1. Find the dependents - which tables have a reference domain pointing at this one. A blocked operation is itself the signal; check domain usage (eddytor get domain-usage) / inspect with get_allowed_values.
2. Remove the dependent reference first - delete_column_domain on the referencing column in the dependent table(s).
3. Then drop / rename / move the source table.

Orphaned data at the S3 layer

drop_table removes the Delta files and deregisters the table, so the object store and Eddytor's discovery stay in sync. Don't delete at the S3 layer instead - that leaves stale discovery / metadata until the next discovery pass. Reach for the storage layer only as a last resort, for orphaned data Eddytor genuinely no longer tracks - see Managing & deleting at the S3 layer.