Try a change and roll it back

Development documentation

This page follows the development branch. For the software and documentation of a released version, consult the published releases.

Download the complete SQL script, including dataset setup for a fresh database.

Add a person and an edge, build a staged graph version, and query the proposal without changing the current version. Then undo both the table changes and the staged build. Run the setup once, then execute the whole script with no other transaction already open. In pgAdmin, leave autocommit enabled for this script’s explicit transaction commands.

Stage and inspect the proposed change

-- Keep the whole what-if scenario inside one transaction, then undo it.
BEGIN;
INSERT INTO warren_examples.people VALUES (10001, 'new-person');
INSERT INTO warren_examples.follows VALUES (1, 10001);

-- The current graph still sees the original 10000 people.
SELECT count(*) AS current_reachable
FROM warren.bfs('example_social', ARRAY[1::bigint], NULL::integer);

DO $$
DECLARE trial bigint; current_id bigint; reachable bigint;
BEGIN
    current_id := (warren.info('example_social') ->> 'current_version')::bigint;
    trial := warren.refresh('example_social', promote := false, label := 'example-trial');
    SELECT count(*) INTO reachable
    FROM warren.bfs('example_social', ARRAY[1::bigint], NULL::integer, version := trial);
    RAISE NOTICE 'Staged version reaches % people', reachable;
    RAISE NOTICE 'Difference: %', warren.diff('example_social', current_id, trial);
END $$;
ROLLBACK;

SELECT count(*) AS source_rows_after_rollback FROM warren_examples.people;
SELECT count(*) AS reachable_after_rollback
FROM warren.bfs('example_social', ARRAY[1::bigint], NULL::integer);

After the inserts, current_reachable is still 10,000 because it reads the existing built version. The staged refresh sees your transaction’s new rows and reaches 10,001, reported under Messages alongside the version difference. It is queryable by its explicit version id but has not been promoted to current.

After rollback, both source_rows_after_rollback and reachable_after_rollback are 10,000. The staged version is gone, and existing persisted vectors still belong to the original version.

Apply the pattern to a scenario

The same workflow can test an edge removal or a facility closure. Make the proposed changes in a transaction, refresh with promote := false, query that explicit version, then choose to roll back or promote and commit. Analyses that omit version continue reading the current graph, so pass the staged id consistently when evaluating a scenario. See graphs and versions.