Checkpoints

Note: 1Transact uses the term "Checkpoints" in its user interface and APIs. In the Oracle Workspace manager SQL API they are called "Savepoints".

A checkpoint is a snapshot of the data at a point in its history, which has been recorded and can be stepped back to.

Certain operations such creating a version will automatically create a checkpoint, and these methods will return the created checkpoint identifier. A checkpoint's identifier is a string that can be created automatically or by the user. Automatically created checkpoints will be given a string identifier generated as a sequential number.

Note: On Postgres, user-created checkpoints are given an identifier and (optionally) a name. This name cannot be made up entirely of numeric characters because when you reference a checkpoint you give it a string to identify it. If that string is entirely numeric the system assumes that you have given the identifier, otherwise it assumes that you have given the name of the checkpoint.

When a checkpoint is created, the current version is moved on past that checkpoint to the latest open state of the version. This open state is like an unsaved checkpoint. Users can modify the data in the version until a new checkpoint is created at which point, the checkpoint records the current state and a the version and session move to a new open state.

A checkpoint exists within a specific version. Sessions that access the data can specify a checkpoint from which to read the data. If not specified then the data will be read from the latest open state of the current version.

Compressing checkpoints

Compressing checkpoints is helpful to reduce storage and keep performance high. If you no longer need to remember the state of the data at a particular checkpoint, merging checkpoints will keep the latest state of the data unchanged but remove the internal details about how the data reached that state.

You can compress checkpoints between any pair of checkpoints that are part of the same lineage. Specify the early checkpoint and the later checkpoint and this function will compress all the checkpoints from the early one to the late one, keeping the late one.

For example if you have checkpoints 1, 2, 3, 4, 5, 6 and 7 then compressing from 2 to 5 will result in checkpoints 1, 5, 6 and 7. You can only compress checkpoints that are redundant (i.e. those which are not used as part of the version hierarchy, such as branch points for child versions).

Rolling back to a checkpoint

Rolling back to a checkpoint removes all edits and checkpoints in that version back to but not including the named checkpoint. This is similar to an undo operation.

For example, if a version has the checkpoints 12, 13, 14 and 15, then rolling back to checkpoint 13 will result in the version only having the checkpoints 12 and 13.