# Getting data into your database

**🔵 Expert · Lesson 09**

PUT YOUR WORLD IN YOUR OWN DATABASE - and notice what melder does NOT do to get it there. This wires a real mesh, seals a real checkpoint, and watches the bytes arrive.

MELDER NEVER IMPORTS YOUR DATABASE. The whole external lane is four callables you write:

store(kind, profile_name, unit_id, payload) -> None fetch(kind, unit_id) -> payload | None list_units(kind, profile_name) -> iterable of ids delete(kind, unit_id)

The contract says it plainly: "one callable, one table with a kind column, any DB stack - melder never imports it." There is no driver, no dialect, no connection string anywhere in the library. `kind` is "checkpoint" / "formation" / "emission", so ONE table with a kind column carries the entire mesh if you want it to.

CALLABLES LIVE OUTSIDE THE RECORD, AND THAT IS A LAW WITH A REASON. Handlers go in a SEPARATE configuration object, and the record "expose[s] handler PRESENCE flags, never callable objects". Why: executable code cannot be serialized into a world record, so a recorded world stays CODE-FREE AND PORTABLE. A record that embedded your storage code would only be restorable somewhere that code already ran.

AN EMPTY CONFIGURATION WILL NOT FREEZE, ON PURPOSE. Upload-on-flush defaults True, so a configuration with no write handler is incoherent - it promises to upload with nothing to upload through. A READ-ONLY deployment must therefore say so out loud by disabling upload-on-flush. The default refuses to let you be vague.

SEAL-THEN-SHIP IS ONE VERB WITH TWO GUARANTEES, AND ONLY ONE OF THEM IS YOURS. `flush_checkpoint` does the local seal AND the remote push, and the remote leg is LENIENT BY DEFAULT: a successful return proves THE LOCAL SEAL and nothing about your database. So this lesson ASSERTS the local seal and only REPORTS what the mesh saw - because asserting the remote would be teaching you to trust the one half the return value does not cover. That is the same rule from the other side: LOCAL CUSTODY IS NEVER HOSTAGE TO A NETWORK YOU DO NOT OWN.

AND TWO DESCRIBE DOORS, WHICH IS NOT REDUNDANCY describe_external_persistence_manager() what is WIRED describe_external_interface() what the CONTRACT is An operator debugging a mesh needs the first; someone implementing handlers needs the second. Neither performs a network call.

## Before you run

Use the [Expert guide](../../expert/index.md) for prerequisite concepts. Run from a checkout with Melder installed and Python 3.14 free-threading selected. The collection download includes the level's local helper modules.

## Run the saved script

```bash
python UX_and_AIX_experiences/04_expert/09_getting_data_into_your_database.py
```

```powershell
py -3.14t UX_and_AIX_experiences/04_expert/09_getting_data_into_your_database.py
```

{download}`Download this collection <../../downloads/expert-examples.zip>` · [Source on GitHub](https://github.com/Synaptic724/melder/blob/90d52e0a12cb0743d62568d5a19ce954a54443bc/UX_and_AIX_experiences/04_expert/09_getting_data_into_your_database.py)

## Public surface

ExternalPersistenceManagerConfiguration with real
                   store/fetch/list_units handlers,
                   configure_external_persistence_manager,
                   create_checkpoint / flush_checkpoint through the mesh,
                   both describe doors, and the absence of any sync verb

## Code

```{literalinclude} ../../downloads/04_expert/09_getting_data_into_your_database.py
:language: python
:linenos:
```

## Check the outcome

The script contains its own assertions or demonstrated refusal paths. Run it to evaluate those checks against your installed version. The code above is taken directly from the saved file; no run output is invented here.

[More expert examples](index.md) · [Level guide](../../expert/index.md)

## Related guides

- [External storage integration](../../expert/external-storage.md)

## API contracts

- [ExternalPersistenceManagerConfiguration](../../reference/api/persistence/externalpersistencemanagerconfiguration.md)