Configuration

Model Forge is configured through the host application's Spring Boot configuration. It reuses the host spring.datasource and does not define a separate Model-Forge datasource.

Host Datasource

For the portal-backend integration the host already provides:

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/portal_backend?sslmode=require
    driver-class-name: org.postgresql.Driver

  jpa:
    database-platform: org.hibernate.dialect.PostgreSQLDialect
    properties:
      hibernate:
        jdbc:
          lob.non_contextual_creation: true

Model Forge uses that DataSource with JDBC/JdbcClient. It does not register JPA entities and does not depend on the host Hibernate model.

At deploy time the host datasource is provisioned as part of the host component; Model Forge needs no component of its own. See Component Configuration → Connecting to Database.

Model Forge Registry

model-forge:
  registry:
    schema: model_forge
    migration-table: model_forge_schema_history

The starter creates a separate Flyway migration for Model Forge:

Property	Default	Description
model-forge.registry.schema	model_forge	Dedicated PostgreSQL schema for Model Forge tables. Currently fixed to model_forge: other values fail startup by design because the SQL statements and migrations are not schema-parameterized.
model-forge.registry.migration-table	model_forge_schema_history	Flyway history table for Model Forge migrations.
model-forge.registry.migrations-enabled	true	Set to false to disable Model Forge's own Flyway migration at startup, e.g. when the host manages schema migration itself.

Host migrations in classpath:db/migration remain host responsibility. Model-Forge migrations live in classpath:db/model-forge/migration.

Data Ownership and Schemas

Host and Model Forge share one database, one datasource and one transaction manager, but own strictly separate PostgreSQL schemas:

Data	Owner	Location
Administration, lifecycle, authorization	Host	host schema (e.g. public), host Flyway
Schema documents, versions, formats, reference graph	Model Forge	model_forge, starter Flyway

The host references model content by versioned CORE URN in a plain text column — no foreign key crosses the schema boundary, and host code never reads model_forge.* tables directly. The ModelForge facade is the only access path; because both sides share the datasource, a host @Transactional method commits its JPA write and the registry write atomically.

CORE URN Namespace

New artifacts that arrive without a CORE URN $id get one generated from the configured namespace segments:

model-forge:
  urn:
    scope: platform
    owner: civitas
    domain: common
    default-version: 1.0.0

External Integrations

Model Forge can import models from two external catalogues. Both are internal adapters behind Model Forge ports; the host decides which workflows expose them.

XRepository (XÖV standards) has one configurable endpoint:

model-forge:
  xrepository:
    base-url: https://www.xrepository.de/api

Smart Data Models needs no configuration: the schemas are fetched from their fixed public GitHub location (raw.githubusercontent.com/smart-data-models/…), there is no API endpoint to point elsewhere. See Smart Data Models Integration for how models are addressed and where to find them.