Why Exasol, feature by feature

Credora uses Exasol as the place where a bank's scattered data meets, is analysed and becomes a decision. This page lists every Exasol feature the project uses, where it is in the code, and why it is the right tool for that job.

An ecosystem of building blocks#

Exasol is more than a database engine. Around it, the exasol and exasol-labs GitHub organisations publish open-source building blocks: virtual schema adapters, script language containers, drivers, an MCP server, a preprocessor framework, a semantic layer and the Exasol Personal launcher. A custom solution picks the blocks it needs and plugs them together, like Lego, instead of building connectors and runtimes itself. Credora is assembled this way:

Each block is independent and versioned, so one can be upgraded or swapped without touching the others. The deploy tool pins the version of every block it downloads. Credora's own code adds only the bank-specific parts: the data model, the API and ML UDFs, the decision logic in Lua, the web app and the infrastructure.

Measured on the live deployment#

SQL preprocessing and the semantic layer#

How the two blocks fit together:

• deploy/credora.py exasol installs preprocessor-framework v0.9.1 (release.sql, sha256-pinned) and exasol-semantic-views v0.5.1 (the release's own installer, from its prebuilt build/install/), then the module, the latest-run views and the model, and last sets ALTER SYSTEM SET SQL_PREPROCESSOR_SCRIPT = PREPROC_RT.MASTER after trying it in one session.
• The semantic views project ships its own preprocessor, SEMANTIC_ADMIN.SEMANTIC_PREPROCESSOR, written to own the slot; the framework lists the integration as a follow-on and ships no module for it. Credora follows the framework's "bring your own preprocessor" contract: PREPROC_RT.SEMANTIC_VIEWS_V1 is a function that takes the statement and returns the semantic compiler's SQL, or nothing. It is registered with PREPROC.MODULE_REGISTER (self-deployed, fronting exasol-semantic-views v0.5.1) and one PREPROC.RULE_ENSURE per role. A semantic query the layer refuses fails with the layer's own message (for example SEMANTIC_QUERY_020: Unknown semantic field).
• Cost for a role user's ordinary statement: about 4 ms (a probe of <schema>.SEMANTIC_DISCOVERY); the compiler is loaded only for statements that read CREDORA_SEM.
• Ask Credora needs no preprocessor tools: every MCP database session, including the new one the MCP server opens after a failed query, gets semantic SQL from the system setting. The tools are switched off (enable_preprocessor_tools: false).

Checks:

SELECT * FROM PREPROC_RT.MY_PIPELINE;            -- what runs on my statements (no rows: nothing)
SELECT * FROM PREPROC_RT.INSTALLED_MODULES;      -- semantic_views, v0.5.1
EXECUTE SCRIPT PREPROC.STATUS;                   -- resolution CURRENT, as a DBA
SELECT industry, approved_companies, pre_approved_amount
FROM CREDORA_SEM.PORTFOLIO GROUP BY industry ORDER BY pre_approved_amount DESC LIMIT 5;

Roll back: ALTER SYSTEM SET SQL_PREPROCESSOR_SCRIPT = NULL; (new sessions; the app's pooled sessions keep their setting until they reconnect). Semantic SQL then needs EXECUTE SCRIPT SEMANTIC_ADMIN.ENABLE_SEMANTIC_SQL(); per session.

After role grants change, run EXECUTE SCRIPT PREPROC.REFRESH; (the deploy tool does).

Upgrading:

• exasol-semantic-views: change SEMVIEWS_VERSION and its sha256 in deploy/exasol_setup.py and re-run credora.py exasol. The installer runs when the pin differs from SEMANTIC_CATALOG.PRODUCT_VERSION, with the system preprocessor off while it replaces the scripts, as the project's upgrade procedure asks.
• preprocessor-framework: release.sql is a clean-install artifact, so the deploy tool runs it only when schema PREPROC does not exist, and records the release as that schema's comment. For a new release, run the framework's idempotent installer (uv run preproc install from its checkout at the new tag, as DBA), which keeps PREPROC.CONFIG, then update PREPROC_VERSION, its sha256 and the schema comment.