Component Interactions¶

Edgy keeps a relatively small API surface, but internally multiple components collaborate closely.

This page maps those interactions so you can reason about runtime behavior and extension points.

What¶

The core runtime components are:

• EdgySettings
• edgy.monkay.instance
• Registry
• Model / QuerySet
• Database objects (default + optional extra)
• signals and model callbacks

Why¶

This map helps when:

• wiring custom startup flows,
• introducing extensions/preloads,
• debugging model registration, schema operations, or query behavior.

How¶

graph TD
    A["EdgySettings"] --> B["Monkay instance"]
    B --> C["Registry"]
    C --> D["Models / Metadata"]
    D --> E["Model.query -> QuerySet"]
    E --> F["Database (main/extra)"]
    F --> G["Rows -> Model instances"]
    G --> H["Signals / callbacks"]

Settings to instance¶

Settings are loaded through EDGY_SETTINGS_MODULE (or defaults), then used by Monkay for preloads/extensions.

See Settings.

Instance to registry¶

The active instance provides the runtime registry and optional app/storages.

See Connection Management.

Registry to models¶

Models register against a registry and contribute SQLAlchemy metadata, including schema behaviors and registry callbacks.

See Models and Registry.

Models to QuerySet¶

Model managers create QuerySets, QuerySets compile/execute SQL, and results become model instances.

See Queries.

Result hooks¶

Signals and related hooks run on write paths (save/update/delete/migrate).

See Signals.

Example¶

If you are adding a custom extension:

1. define extension + preload settings in your custom EdgySettings,
2. ensure the app/instance path is preloadable for CLI/runtime commands,
3. validate query lifecycle using edgy shell and migration commands.

See CLI Commands and Migrations.

See Also¶

• Getting Started
• How-To Guides
• Settings
• Architecture Overview