floppy-disksSnapshots — Getting Started

This guide shows how to save, list, and load system snapshots using SPX. Snapshots capture the structure of your system (models, instances, and connections) so you can quickly persist and restore configurations.

What a snapshot captures

  • Model templates (their definitions)

  • Instances (which instance uses which template)

  • Connections (wiring between instances)

What it does not capture (MVP)

  • Runtime state (thread state, attribute runtime values, timers, …) Snapshots currently rebuild structure; runtime state always starts “fresh”.


Prerequisites

  • SPX Server with API v3 enabled (verify GET /health returns "api_version":"v3").

  • Your System has the snapshots component mounted (this is default in recent builds).

  • spx-python client connected to your server (examples below).


Quick Start (with spx-python)

1) Save a snapshot (default, durable)

By default, calling save() with no arguments creates an in-memory snapshot and persists it to disk (durable mode). You get a unique id and a persisted_path.

Example output:

2) List available snapshots

Example output:

3) Load a snapshot

You can load by path or by id.

By path:

By id (when persisted in durable mode, the manager locates the file under the configured directory):

Effect of load()

In the standard configuration, load() replaces the active System in place (runtime replace). This means further API calls operate on the newly loaded system structure.


Saving to a specific file

If you want a deterministic file name and location:

Or compose from directory + name:

You can optionally attach metadata:


Persistence behavior

  • Durable-by-default: The default save() persists to disk (and still returns an id for convenience).

  • In-memory only: If your setup is configured for non-durable mode, in-memory saves do not create a file (the response will have persisted_path: ""). You can later persist all in-memory snapshots with:

Tip

The snapshot file includes minimal metadata (id, timestamp, optional label/notes) and the structure definition. Schema evolution is handled by a simple schema_version field inside the file.


Using the generic API v3 endpoints (HTTP)

All operations can be performed via the generic “call method” endpoint on the snapshots component:

  • Save POST /api/v3/system/snapshots/method/save Body (optional):

    Response includes id and, in durable mode, persisted_path.

  • List POST /api/v3/system/snapshots/method/list Body:

  • Load by id POST /api/v3/system/snapshots/method/load Body:

  • Load by path


Troubleshooting

  • “File not found” on load by id Ensure the snapshot was saved in durable mode or the manager is configured with the same base directory used when saving.

  • No models/instances after load Snapshots capture structure. If you are exploring the live tree immediately after load(), confirm your System populates children during initialization. You can always inspect the stored definition inside the loaded system (implementation may expose it as definition or definition_snapshot for debugging).

  • Different IDs between file name and snapshot id Depending on configuration, file names may be derived from either the snapshot id or another chosen naming scheme. Always rely on list() to map ids to file paths.


Minimal end‑to‑end example

That’s it! You now know how to persist and restore system structure using SPX Snapshots.

Last updated