uni-plugin 2.0.6

Plugin framework for uni-db: registry, manifest, and capability traits
Documentation

Plugin framework for uni-db.

uni-plugin defines the trait surface, registry, manifest, and capability model that every uni-db extension — scalar function, aggregate, procedure, storage backend, index kind, graph algorithm, CRDT, hook, trigger, background job, logical type, auth provider, authz policy, connector, collation, CDC output, catalog, replacement scan, Pregel program — registers through.

The crate intentionally has no host integration: it does not depend on uni-query, uni-store, uni-crdt, uni-algo, or uni. Those crates depend on uni-plugin and adapt their existing surfaces to the traits defined here. This direction keeps the dependency graph acyclic and lets the trait surface be reviewed in isolation.

Layout

  • [plugin] — the Plugin trait, PluginManifest, PluginHandle.
  • [qname] — qualified plugin-function names (namespace.local).
  • [capability] — Capability, CapabilitySet, Determinism, Scope.
  • [manifest] — TOML / JSON manifest (de)serialization.
  • [registrar] — the builder a plugin's register() method calls.
  • [registry] — per-surface trait-object tables (arc-swap-backed for wait-free reads).
  • [traits] — one module per extension surface (scalar functions, aggregates, procedures, hooks, …).
  • [errors] — PluginError, FnError, plus per-trait error helpers.

Stability

Until uni-plugin reaches 1.0.0, trait shapes may change. The semver guarantees apply only to 0.x major versions in the meantime.

Examples

use uni_plugin::{Plugin, PluginManifest, PluginRegistrar, PluginError, QName};

struct NoopPlugin;

impl Plugin for NoopPlugin {
    fn manifest(&self) -> &PluginManifest {
        // In real plugins, store the manifest in a `OnceLock` populated
        // at construction.
        unimplemented!("see crates/uni-plugin-builtin for real examples")
    }
    fn register(&self, _r: &mut PluginRegistrar<'_>) -> Result<(), PluginError> {
        Ok(())
    }
}