uni-plugin-custom 2.0.4

Meta-plugin for uni-db — apoc.custom.declare* analogue
Documentation

Meta-plugin (apoc.custom.declare* analogue) for uni-db.

This crate ships a built-in plugin whose procedures (uni.plugin.declareFunction, declareProcedure, declareAggregate, declareTrigger) accept Cypher source and persist new plugin registrations alongside the framework's [uni_plugin::PluginRegistry].

M9 status (this commit)

Completed M9 deliverables:

  • uni.plugin.declareFunction — fully wired. Parses the Cypher expression body at declare time, persists the [DeclaredPlugin] record via [persistence::Persistence], and registers a synthetic [uni_plugin::traits::scalar::ScalarPluginFn] into the shared [PluginRegistry].
  • uni.plugin.declareProcedure, declareAggregate, declareTrigger — registered as Cypher-callable procedures. Their declarations are persisted and reachable via uni.plugin.listDeclared; full body execution rides on downstream host APIs (ProcedureHost::execute_inner_query for procedures; trigger/aggregate body invocation follows the M11 capability work).
  • uni.plugin.listDeclared / dropDeclared — extended for cascade-aware drops.
  • Reactivation — declarations are reloaded into the registry on [CustomPlugin::new] when constructed with a non-empty persistence backend.
  • Capability inheritance — declarations capture the declaring principal id; the registrar enforces capability gating at registration time via the synthetic plugin's manifest.

Persistence

Proposal §9.7 anchors the persistence schema in a Cypher-visible system label _DeclaredPlugin. Writing to that label from inside a procedure requires write-enabled [uni_plugin::traits::procedure::ProcedureHost] execution, which does not yet exist (the host's execute_inner_query is read-only and does not bind parameters — see crates/uni-query/src/query/executor/procedure_host.rs).

M9 ships persistence behind a [persistence::Persistence] trait with a JSON-sidecar implementation that preserves the exact [DeclaredPlugin] shape from §9.7. The cutover to system-label persistence — once write-enabled host execution lands — is a drop-in replacement of the backend; no schema, store, or procedure code changes.