ToolRegistry.h File Reference

In-memory catalog of the external tools ProvSQL can invoke. More...

#include <string>
#include <utility>
#include <vector>

Include dependency graph for ToolRegistry.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
struct	provsql::ToolRecord
	One registered external tool. More...
class	provsql::ToolRegistry
	The process-local registry singleton. More...

Namespaces
namespace	provsql

Functions
std::string	provsql::expandCommandTemplate (const std::string &tpl, const std::string &binary, const std::string &in, const std::string &out, const std::vector< std::pair< std::string, std::string > > &extra={})
	Expand a command template into a runnable shell command line.
ToolRegistry &	provsql::tool_registry ()
	Shorthand for ToolRegistry::instance().

Detailed Description

In-memory catalog of the external tools ProvSQL can invoke.

ProvSQL shells out to several knowledge compilers / model counters / visualisers (d4, d4v2, c2d, minic2d, dsharp, ganak, weightmc, graph-easy). Historically the set of tools, their executable names, and which one is preferred for a given operation were compiled in as string literals scattered across a dozen call sites. This registry turns that into a single in-memory table of provsql::ToolRecord, so the dispatchers query metadata instead of testing literals.

The registry is seeded at first use with exactly the tools ProvSQL has always known about, with their current invocations and a default preference order, so the out-of-the-box behaviour is unchanged: a fresh backend behaves identically with no registration call. An administrator may then add / repoint / reorder / disable tools at run time through the SQL surface (provsql.register_tool, provsql.unregister_tool, provsql.set_tool_enabled, provsql.set_tool_preference, and the read-only provsql.tools view).

Lifetime

The catalog is process-local (one copy per PostgreSQL backend), seeded from compiled-in defaults and mutated in memory. It is therefore per-session and transient: registrations are visible only within the backend that made them and are reset when the session ends. This is the deliberate first-stage backing; a future stage may back it with a shared catalog table without changing this interface.

Standalone tdkc

The standalone tdkc tool deliberately uses no external tool, so it does not link this registry: every reference to it in BooleanCircuit.cpp is guarded by #ifndef TDKC. Keep this header free of any PostgreSQL or external-tool dependency so it stays a self-contained piece of metadata.

Definition in file ToolRegistry.h.