Deploy cart

functional

Collect objects from any connection into a cart and generate one dependency-ordered script.

The Deploy Cart collects tables, views, procedures, and functions from any of your connections into a named list. From that list you generate one dependency-ordered script to review and run somewhere else, or write one file per object. It's built for jobs like “move these five objects to staging”, where comparing whole schemas is overkill and a data transfer copies only rows.

Collecting objects

Right-click a table, view, procedure, or function and open the Deploy Cart submenu (materialized views can't be collected):

Add to Deploy Cart adds the object's structure.
Add with Data (tables only) also carries the table's rows, as INSERT batches after the structure.
Open Deploy Cart… opens the cart window. You can also run Deploy Cart… from the command palette.

Items go into the active cart. Adding an object that's already there does nothing, and adding it again with data switches data on for the existing entry. Carts are saved on disk, so they're still there after a restart. If the carts file is damaged, SQLly says so and leaves it untouched instead of replacing it with an empty cart.

The Deploy Cart window: items grouped by source connection and database, with data checkboxes on tables and the Generate script button.

The cart window

Carts: switch carts with the picker, create one with New, or Delete… one (SQLly asks first). To rename a cart, edit the name field and press Enter or click away. Cart names are unique; a name another cart already uses is refused. The cart you pick becomes the active cart for future adds.
Items are grouped by source connection and database. The arrows set the order objects appear in the generated script and exported files, as far as dependencies allow (see below). ✕ removes an item, and the data checkbox on a table includes or drops its rows. Clear cart… empties the cart after asking.
Open scripts on picks the connection each generated script tab opens on. The default is each group's source connection. Pick your staging or production connection to review and run the script there. Scripts are not translated between engines, so a group whose source is a different engine family from the target (SQL Server to PostgreSQL, for example) is listed under the picker and skipped when you generate.

Generating

Generate script builds one script for each source database in the cart, from the objects' live definitions. Tables come first, each after the cart's tables its foreign keys point to; views and routines follow, each after the cart's views and routines its definition refers to. Where no dependency decides, the cart's own order is kept. Objects whose definition can't be read appear as -- SKIPPED comments, and ordering problems such as circular references appear as warnings in the script header.

For tables marked data, the rows follow the structure as INSERT batches, parents before children. The rows are staged in a private temporary file that only your user account can read, and the file is deleted as soon as it has been read into the tab. A script can be at most 8 MB, because it opens in an editor tab: once the data would pass that limit, SQLly stops reading rows and tells you to use Files… instead. Each script opens in a new tab for review, and the cart never executes anything.

While a script or export is running, Cancel run stops it. Nothing from a cancelled run opens in a tab. Closing the cart window also cancels.

Files… asks for a folder and writes one file per object into <folder>/<cart>/<connection>-<database>/, using the same file-per-object layout as Export Database as SQL: a structure folder, a data folder for tables marked data, header and epilogue files, and a manifest.sql that runs them all. The structure files are numbered (001_…, 002_…) in the same dependency order as the generated script, including the cart's arrow order where no dependency decides, so running them by number (or through the manifest) creates each object after what it depends on. Data files follow, parents before children. When a definition can't be read, or references go in a circle, the status bar shows a warning with the export result. Each export gets a folder of its own: if that folder already exists, or two groups would share a name, SQLly adds -2, -3, and so on, so one export never overwrites another's files.

A cart item remembers its connection by identity. If you delete that connection, its group is skipped with a warning and the rest of the cart still generates. The Deploy Cart needs the desktop app. The browser preview doesn't show it.