If want to dry-run your migrations, replace withRunMode() by
withDryRunMode(Paths.get(outputDirectory)), where
outputDirectory specifies the path of the directory where
output.cypher will be written in.

By default the migration file is read from
${your_project}/src/main/resources/db/liquigraph/changelog.xml.
This can be changed using the liquigraph.change-log property in any
supported
configuration source.
Other settings can be found in
LiquibaseProperties.

Both sub_changelog.xml files could import changelogs and/or define
changeset elements. Their root element is also changelog.

Changeset

A Liquigraph changeset describes one or more create or update statement. These
statements must be written in
Cypher Query Language
and are wrapped in a single transaction (1 transaction per
changeset). A changeset can be run only once (incremental) and cannot be altered
(immutable) against the same graph database instance, by default. Finally, a
changeset is uniquely identified within the changelog by its mandatory ID and author
attributes.

If no execution contexts are specified at runtime, all changesets will match.
If one or more execution contexts are specified at runtime, changesets will be
selected:

if they do not declare any execution contexts

or one of their declared contexts match one of the runtime contexts

Changeset immutability

As previously mentioned, Liquigraph changesets are immutable by default (an error
will be thrown if they have been altered). That said, there may be situations where
changesets should be run whenever their contents have changed. To achieve this, you
just need to define one extra attribute:

As previously mentioned, Liquigraph changesets are incremental by default (they will
be executed only once). That said, there may be situations where changesets should
be run at every execution. To achieve this, you just need to define one extra
attribute:

In any case, each of the subqueries/the simple query has to return exactly
one column named result of type boolean (true|false).

Note that a postcondition cannot modify the database itself: all changes will be
rolled back.

Once the postcondition returns false, the changeset is considered complete.

A repeatable changeset can be used to perform a migration on a large database
without risking an OutOfMemoryError because of the large number of nodes or
relationships impacted, by splitting the migration into smaller batches.

Here is a postcondition example, deleting all relationships in the database by
batches of 10: