How deployments work

A deployment runs the SQL that makes one database match the other, for the differences you choose. Start it with Deploy on a comparison. The wizard has three steps: Choose changes, Review SQL and Deploy.

Step 1: Choose changes

Direction

Card	Direction	Use
Update the target (Y)	X → Y	Make the target match the source. The usual choice.
Update the source (X)	Y → X	Make the source match the target, for example to pull a hotfix back.

The wizard’s header names the database that will change.

Differences

Every difference is selected when the wizard opens.

• Filter differences filters by name or type.
• All and None select or clear every difference.
• The Will column says what deploying does to each object in the chosen direction: Create, Drop or Alter.

Choose Generate SQL to write the script and go to step 2. Changing the direction or the selection later discards the script.

Step 2: Review SQL

The script shows how many statements it has and how it runs: “runs in one transaction” on PostgreSQL and SQL Server, “runs statement by statement” on MySQL. Choose Copy SQL to copy it.

Warnings

Above the script, Parallax explains its risks, most serious first:

Message	Meaning
“<n> statement(s) permanently delete(s) data: …”	The script drops tables or columns. It names each one, such as drop table orders or drop column customer.legacy_code.
“<n> difference(s) cannot be deployed automatically and will stay different: … Apply these by hand.”	Parallax cannot script these differences.
“<n> statement(s) alter(s) or recreate(s) existing objects: …”	These changes touch objects that already exist, and may hold data.
“MySQL cannot roll back schema changes…”	MySQL only. If a statement fails, the ones before it stay applied. Take a backup or snapshot first if the changes matter.
“Not rehearsed: a failure part-way leaves the target partly changed.”	MySQL only, when rehearsing is unticked.
“The two sides use different schemas: objects from <from> are created in <to>.”	The source and target name different schemas.
“<n> rename(s) first, keeping the rows: …”	Declared renames run first, under -- Renames. See Renames.
“Only additive changes: nothing is dropped or rebuilt.”	There is nothing to warn about.

Long lists show the first five names. Choose and <n> more to see the rest.

Pre- and post-deployment SQL

Open Pre- and post-deployment SQL (optional) to add your own SQL:

• Runs before the changes, for example SET lock_timeout = '5s';
• Runs after the changes, for example ANALYZE;

Confirm data loss

When the script deletes data, tick I understand this permanently deletes data in <database>. Until you do, the deploy button is not available (“Confirm the data loss above first”). The button is red when the script deletes data.

Deploy

Choose Deploy to <connection>, then Deploy now in the confirmation. The confirmation says how the script runs:

• PostgreSQL and SQL Server: “in one transaction. If any statement fails, nothing is changed.”
• MySQL: “one by one. If one fails, the statements before it stay applied.”

Choose Back to return to step 1.

Step 3: Deploy

Checking the databases are as compared

Before it changes anything, Parallax compares the two databases again (“Checking the databases are as they were compared”). If nothing changed, it goes on.

If something changed, Parallax says “The databases changed since they were compared” and lists each object and how it changed. Choose:

• Compare again (the default): close the wizard and open the new comparison. Nothing is deployed.
• Deploy anyway: deploy the script as it is.

How it runs

Engine	How the deployment runs
PostgreSQL	In one transaction. If anything fails, nothing changes.
SQL Server	In one transaction. If anything fails, nothing changes.
MySQL	Statement by statement, since MySQL cannot roll back schema changes. Parallax first checks the target’s rows and rehearses the script.

The step shows a timestamped log of the deployment as it runs.

MySQL: checks of the target’s rows

On MySQL, the script starts with checks of the target’s rows. Each counts the rows that would make a change fail: duplicates under a new unique index, NULLs under NOT NULL, rows without a parent under a foreign key, values too big for a smaller column, or rows a check would reject. If any count is not 0, the deployment stops before its first change.

MySQL rehearsal

On MySQL, Parallax first runs the deployment on a scratch database holding an empty copy of the target’s schema, on the same server. A script that fails there stops before the target changes.

The rehearsal needs the right to create its scratch databases:

GRANT ALL ON `parallax\_preflight\_%`.* TO 'your_user'@'%';

Without it, the deployment fails before changing anything: “Nothing was changed: the deployment could not be rehearsed first”. Grant the right, or untick Rehearse on a scratch database first in step 2 to deploy without rehearsing.

Rehearsing is on by default. The project’s Rehearse deployments on a scratch database first option sets the wizard’s default. The connection’s Rehearse deployments first option, when off, also skips it. A deployment that was not rehearsed says so in its result.

Cancel

Choose Cancel deployment while it runs. Parallax says “Cancelling…”, then “Deployment cancelled” and what it left:

• PostgreSQL and SQL Server: the changes are rolled back.
• MySQL: the statements before the cancel stay applied.

The result

After a successful deployment, Parallax compares the databases again to confirm. It then says “Deployment complete”, how many statements it deployed, and either “The databases now match.” or how many differences remain, such as ones you did not select.

Choose View the new comparison to open the comparison made after the deployment. The comparison you deployed from becomes history.

After a failure, Parallax says “Deployment failed” with the error and what the failure left:

• “The transaction was rolled back; nothing changed.”
• On MySQL: “Statements before this one stayed applied.” or how many statements were applied.

Choose Back to the script to return to step 2.

An account without the right to change the target fails with the server’s reason, and changes nothing.

After a failed deployment

1. Read the error in the result, or in Deployments.
2. If the deployment was rolled back, fix the cause and deploy again from the same comparison.
3. If some changes stayed applied (on SQL Server or MySQL), compare again before deploying. The comparison then shows what is left to deploy.

The comparison you deployed from shows a banner about the failed deployment, with See the deployment.

The Deployments page

Open Deployments to see every deployment, newest first. Each row shows the target, the project (or “No project”), the number of changes, Succeeded or Failed, and when it ran.

• Choose a row to see what it ran: the number of changes, the error if it failed, and “The script that ran”, with Copy SQL.
• Before opens the comparison it was deployed from. After opens the comparison made right after it, or reads “not compared”.
• Compare again compares the databases as they are now and opens the new comparison.
• Delete deletes the record of the deployment. It does not change any database.