Database Modularization

Modularized ADITO modules should define their own database tables and changes using alias definitions and Liquibase files.

Alias definitions and targetAliasName

Each module that introduces its own tables must define a dedicated Alias Definition. This includes the structure of the tables (AOD files) and links to Liquibase changelogs.

• The Alias Definition must set the targetAliasName property.
• This defines the central alias into which it will be merged (usually Data_alias or _____SYSTEMALIAS).
• Target aliases like Data_alias can be located in any package.
• If the required target alias is not present in the current module, you can add it later via modifications.
• In the Designer, you can specify the module's alias in any property that requires the alias. During transpilation, occurrences of the module aliases are replaced with the target alias. This allows module development to reference only its own alias; the project provides the final targetAliasName.

Liquibase structure per module

Create changelogs and changesets in each module as you would in a single-module project.

• Liquibase can operate on the module's own alias.
• To avoid executing many separate Liquibase scripts, reference each module's root changelog from the target alias's changelog.

changelog.xml

<?xml version="1.1" encoding="UTF-8" standalone="no"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" 
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.4.xsd">
	<include relativeToChangelogFile="true" file="../Language_alias/changelog.xml"/>
	<include relativeToChangelogFile="true" file="../Keyword_alias/changelog.xml"/>
	<include relativeToChangelogFile="true" file="../Attribute_alias/changelog.xml"/>
	<!-- ... -->
</databaseChangeLog>

This merged changelog aggregates all module changelogs and enables unified execution in the Designer or via CLI.

Executing Liquibase

Designer and Liquibase Plugin

The Designer supports executing Liquibase from the dist/ folder when the checkbox "Execute in transpiled directory (dist)" is enabled.

Figure: Liquibase plugin dialog for Liquibase update

• Contexts are loaded from dist.
• If no transpile has run, click "Partial Transpile" first to avoid stale files.
• Compatible with modularized changelog structures.

VS Code extension or CLI

Use the Liquibase CLI or the ADITO Liquibase VS Code extension:

• Execute against the dist folder.
• Ensure the merged changelog.xml is present.
• The extension supports update, dropAll, clearChecksums, etc.

warning

Liquibase checksums may differ between tools (CLI vs. Designer plugin). After switching tools, run "Clear Checksums" if needed.

Avoiding changes to existing tables

To maintain upgrade safety and modularity:

• Do not modify shared/core tables or columns from other modules unless strictly necessary.
• Prefer new module-specific tables with their own aliases and structures.
• If a change to an existing table is unavoidable, add columns via Liquibase changesets cautiously and document the rationale.
• Often a separate table with foreign keys to shared tables is the better modular approach.

ADITO developers should evaluate each case individually. As modularization matures, formal best practices will be defined.