Chelabase
ManagementMerges

Rehearse a draft merge

POST
/v1/databases/{id}/merges/{merge_id}/rehearse

Runs the plan on a throwaway branch of the target (real data, so a failing constraint shows) and compares the result with the merged schema. Needs a draft with a plan and no open conflicts. Success makes the merge rehearsed; a failure returns it to draft with the failing step and the Postgres error in rehearsal. Send the version you last saw: the rehearsal then runs that draft.

Authorization

bearer
AuthorizationBearer <token>

In: header

Path Parameters

id*string

Database id

Formatuuid
merge_id*string

Merge id

Formatuuid

Request Body

application/json

Optional; an empty body is {}

TypeScript Definitions

Use the request body type in TypeScript.

version?|

The version you last saw; another one is a 409 merge_version_conflict.

Formatint64

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/v1/databases/497f6eca-6276-4993-bfeb-53cbbbba6f08/merges/497f6eca-6276-4993-bfeb-53cbbbba6f08/rehearse" \  -H "Content-Type: application/json" \  -d '{}'
{  "created_at": "2019-08-24T14:15:22Z",  "created_by": "string",  "database": "string",  "direction": "into_parent",  "error": "string",  "failed_phase": "string",  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "rebaselined": true,  "source_branch_id": "345f76de-8f9d-4a8f-b08e-a28a3db17483",  "status": "computing",  "target_branch_id": "2a8880d3-8c08-4fef-81e0-ec9d6c6def29",  "updated_at": "2019-08-24T14:15:22Z",  "version": 0}

Recompute a merge from the schemas as they are now POST

From `draft`, `stale` or `failed` (not a failure in the online phase: retry that one). The worker reads both schemas again and returns a new draft that keeps the resolutions whose conflicts are unchanged. `rebaseline: true` uses the target's current schema as the base when the real one is gone (`merge_base_unavailable` in `error`): every difference then counts as a source change, so the target's own recent changes show as things to undo.

Retry a merge that failed while applying POST

For a `failed` merge whose `failed_phase` is `roles`, `enum_add`, `tx` or `online`. Failed in `online`: the plan's transaction is committed and the target changed; only the online steps (concurrent indexes, constraint validation) are left, and the worker continues where it stopped (a valid index is skipped, an invalid one is dropped and rebuilt); the merge is `online` again. If the plan's transaction is no longer on the target, or the target is gone, the merge fails for good. Failed before (`roles`, `enum_add`, `tx`): the worker first checks whether the plan's transaction committed after all (its answer may have been lost); if it did, it goes on to the online steps; if not, the apply runs again from the start, with its checks (a target that changed since the merge was computed makes it `stale`; roles and enum values the first attempt made stay); the merge is `applying` again.