Benerator-Modelle nach DATAMIMIC migrieren

Behandle eine Migration als semantische Neufassung, nicht als Umbenennung von XML. Ermittle zuerst, was jede Benerator-Komponente liest, erzeugt, transformiert und konsumiert. Drücke dieses Verhalten danach mit Elementen und Attributen aus der aktuellen implementierungsgenerierten Modellreferenz aus.

Häufige Zuordnungen

Benerator-Konzept	DATAMIMIC-Vertrag	Migrationsabsicht
<attribute> oder <id>	<key>	Ein Feld in das aktuelle Produkt schreiben.
<setting> pro Datensatz	<variable>	Einen wiederverwendbaren Wert auswerten, ohne ihn direkt zu schreiben.
<part>	<nestedKey>	Ein verschachteltes Objekt oder eine Liste aufbauen.
consumer	target	Ein in der Implementierung registriertes Ziel auswählen.
type als Produktname	name	Dem Produkt einen expliziten Ausgabenamen geben.
BEN-/JavaScript-Ausdruck	Python-Ausdruck in script	Namensauflösung und Typverhalten erneut testen.

<iterate> durchläuft eine erforderliche Quelle und stellt den aktuellen Datensatz in Kindkontexten bereit. Im aktuellen Authoring-Vertrag besitzt es kein Target. Verwende <generate>, sobald die Operation ein Produkt erzeugt oder exportiert. Die Runtime akzeptiert ältere target-behaftete iterate-Descriptoren weiterhin, damit sie kontrolliert migriert werden können.

Migriere nicht anhand einer historischen statischen Supporttabelle. Die generierten Referenzen für Generatoren, Scripting, Quellen und Ziele stammen aus exakt der EE-Version, welche die Platform verwendet.

Den offiziellen Benerator-Converter ausführen

Verwende den Converter aus dem offiziellen Benerator-CE-Projekt, fest auf Release 4.0.1-jdk-11 gesetzt. Das Release benötigt JDK 11. Die versionierte Migrationsanleitung und das Migration Playbook beschreiben den Converter und die Fälle, die geprüft werden müssen.

Baue den getaggten Quellstand und starte den Converter mit dem vollständigen Maven-Abhängigkeits-Classpath:

git clone --depth 1 --branch 4.0.1 https://github.com/rapiddweller/rapiddweller-benerator-ce.git
cd rapiddweller-benerator-ce
java -version
mvn --batch-mode -DskipTests -Djacoco.skip=true compile
mvn --batch-mode -DskipTests -Djacoco.skip=true dependency:build-classpath -Dmdep.outputFile=target/runtime-classpath.txt
java -cp "target/classes:$(cat target/runtime-classpath.txt)" com.rapiddweller.benerator.main.datamimic.DatamimicConverter /path/to/benerator-project /path/to/datamimic-project /path/to/datamimic-project/migration-report.txt

Das dritte Converter-Argument ist ein optionaler Reportpfad. Ersetze diesen Aufruf nicht durch einen Classpath, der nur das Haupt-JAR aus Maven Central enthält: Dieses JAR enthält nicht alle Laufzeitabhängigkeiten des Converters.

Der Converter erzeugt *.datamimic.xml, kopiert Projektressourcen, migriert Environment-Dateien und schreibt migration-summary.md. Wenn ein Reportpfad angegeben wurde, schreibt er zusätzlich den detaillierten Report dorthin. Behandle beide Reports als Arbeitsliste, nicht als Nachweis für ein bereits lauffähiges migriertes Projekt.

Ein verschachteltes Produkt neu formulieren

<setup>
    <generate name="persons" count="5" target="LogExporter">
        <key name="name" values="'Alice','Bob','Charlie'"/>

        <nestedKey name="notes" type="list" count="1">
            <key name="pet" constant="Dog"/>
            <key name="hobby" values="'Skiing','Sailing'"/>
        </nestedKey>

        <nestedKey name="cars" type="list" minCount="0" maxCount="3">
            <key name="model" values="'Audi Q4 e-tron','Tesla','VW Passat','BMW iX'"/>
            <key name="color" generator="DataFakerGenerator('color_name')"/>
        </nestedKey>
    </generate>
</setup>

Werte auf Root-Ebene sind im ersten Generate-Frame direkt sichtbar. Verschachtelte Scopes sollten lokale Werte mit this.* und Elternwerte mit this.parent.* qualifizieren; siehe Variablen-Scope in verschachtelten Generates.

Datums-Converter ersetzen

Bei textueller Eingabe legt inDateFormat das Parseformat fest. outDateFormat definiert die gewünschte Ausgabedarstellung.

<generate name="dates" count="1">
    <key name="created" constant="2026-07-30" inDateFormat="%Y-%m-%d" outDateFormat="%d.%m.%Y"/>
</generate>

Migrationscheckliste

1. Ersetze nicht unterstützte Strukturkonzepte durch registrierte Elemente; Verhalten darf nicht still entfallen.
2. Ersetze jeden Consumer durch ein explizites Ziel oder verzichte bewusst auf Export.
3. Ändere jedes konvertierte <iterate target="X"> mit nichtleerem Target zu <generate target="X">.
4. Entferne bei <iterate target=""> das leere Target und behalte iterate nur, wenn Kindkontexte den aktuellen Quelldatensatz tatsächlich verwenden. Formuliere die Stufe andernfalls mit dem Konstrukt neu, das ihren wirklichen Zweck ausdrückt.
5. Portiere Ausdrücke nach Python und mache verschachtelten Scope-Zugriff explizit.
6. Wähle Generatoren und Converter aus den versionierten generierten Katalogen.
7. Führe die LSP-Validierung aus, prüfe migration-summary.md, den optionalen Report und das Migration Playbook und starte danach einen kleinen deterministischen Task, bevor du die Menge erhöhst.
8. Prüfe benutzerseitige Issue-Codes und korrigiere nicht unterstützte Optionen, statt sie zu unterdrücken.

Der Converter übernimmt die mechanische Projektmigration. Die Prüfschritte bleiben verpflichtend, weil die Ausgabe von Benerator 4.0.1 target-behaftete iterate-Elemente enthalten kann, die der aktuelle DATAMIMIC-Authoring-Vertrag bewusst generate vorbehält.