Modelle von DATAMIMIC 3.5 auf 4.0 umstellen

Du musst nicht jedes Modell neu schreiben. Suche in der Checkliste nach den Funktionen deiner Projekte und bearbeite nur die passenden Migrationsschritte. Unbekannte Attribute und ungültige Werte führen weiterhin zu Fehlern. Die unten aufgeführten alten Schreibweisen bleiben mit einer Warnung ausführbar: Ungenutzte Einstellungen werden ignoriert, die alte Memstore-Datensatzauswahl wird in sourceEntity umgewandelt.

Diese Anleitung behandelt XML-Modelle und ihre Ausgabe. Deployment, Anmeldung, Environment-Variablen und APIs sind separate Upgrade-Themen. Für einen Wechsel von Benerator verwende stattdessen den Benerator-Migrationsguide.

Warum gibt es diese Änderungen?

4.0 macht Modelleinstellungen eindeutiger und erkennt mehr Fehler, bevor sie deine Daten beeinflussen. Ein falsch geschriebener Optionsname oder ungültiger Wert meldet weiterhin einen Fehler. Einige harmlose alte Deklarationen werden mit einer Warnung akzeptiert, damit bestehende Modelle nicht allein für die Ausführung bereinigt werden müssen. Die Warnung empfiehlt eine optionale Bereinigung; sie reaktiviert die alte Einstellung nicht. Bei einer Bereinigung soll klar sein, ob sie einzelne Datensätze oder einen ganzen Datenbestand löscht. Tests mit Seed sollen sich nicht allein deshalb ändern, weil sie an einem anderen Tag laufen.

Diese Verbesserungen erfordern beim Upgrade etwas Arbeit: Manche alten Einstellungen musst du ändern, und manche Modelle liefern andere Werte. Jeder Abschnitt erklärt, wann du betroffen bist, was die Änderung verbessert und was du tun musst. Nutzt du die Funktion nicht, überspringe den Abschnitt.

Welche Änderungen betreffen mich?

Wenn dein Projekt Folgendes nutzt…	Vor dem Upgrade prüfen
Seeds, Zufallsausdrücke oder exakte Referenzausgaben	Zufallswerte und Reproduzierbarkeit
Hash, gespeicherte Pseudonyme oder gehashte IDs in Joins	Hashes und verknüpfte IDs
Aktuelle/relative Datumswerte oder Datumsgewichte	Datumswerte und Gewichtsausdrücke
Alte Attribute oder type zur Auswahl eines Datenbestands	XML-Attribute und Elementnamen
<memstore> oder Daten, die spätere Generierungsschritte wiederverwenden	Memstore: Schreiben und Lesen mit mem
.wgt.ent.csv-Dateien	Gewichtete Entity-Quellen
Kafka-Eingaben oder ML-Modellquellen	Begrenzte Quellen und unterstützte Optionen
Datenbank-Löschung oder Bereinigung	Delete, Clear und Drop
Template-Verarbeitung mit <operate>	Template-Verarbeitung und Exportziele
<ama-generate> oder AMA/EDIFACT-Templates	AMA-Deklarationen und Referenzen
Zyklische Datenbankabfragen, mehrere Einzeldatei-Exporte oder vollständige Company-Entities	Datensatzanzahl und Ausgabedateien
Eigene Python-Generatoren oder direkte EE-Imports	Python-Erweiterungen

Sichere vor dem Test dein 3.5-Projekt, referenzierte Eingabedateien, Konfiguration und Referenzausgaben. Verwende ein separates Testziel, besonders bei Datenbank-Schreibzugriffen und Pseudonymen. Ein erfolgreicher Lauf reicht nicht: Prüfe Datensatzanzahl, IDs, Beziehungen, Datumswerte und Ausgabeorte, bevor du neue Referenzausgaben übernimmst.

Zufallswerte und Reproduzierbarkeit

Relevant für dich, wenn: deine Tests exakte erzeugte Werte vergleichen, du auf denselben Seed vertraust oder Ausdrücke random.seed(...) beziehungsweise secrets.* verwenden.

Was sich ändert und warum: Alle Generatoren verwenden jetzt dieselbe Verwaltung für Zufallswerte. Jeder Modellschritt, jedes Feld und jeder Datensatz erhält eine eigene Zufallsfolge. So wiederholen unabhängige Felder nicht versehentlich dieselbe Folge. Die Konsequenz: Derselbe Seed kann unter 4.0 andere Werte liefern als unter 3.5. Läufe ohne expliziten Seed erhalten auch keinen versteckten Seed mehr aus der Task-ID.

So migrierst du:

1. Setze rngSeed auf <setup>, wenn du Reproduzierbarkeit benötigst. Ein vorhandener expliziter Seed kann bleiben, die erwarteten Werte musst du aber prüfen.
2. Entferne random.seed(...) aus Ausdrücken: Der Aufruf läuft weiterhin, setzt aber keinen Seed mehr. Ersetze secrets.* durch einen unterstützten Generator oder Ausdruck aus der Scripting-Referenz.
3. Prüfe zuerst die fachlichen Regeln und übernimm erst danach neue 4.0-Referenzausgaben. Müssen zwei Felder gleich sein, verwende den berechneten Wert wieder. Verlasse dich nicht darauf, dass unabhängig erzeugte Felder zufällig übereinstimmen.
4. Halte Engine-Version, vollständige Eingaben, Quell-Snapshot/-Reihenfolge und Ausführungseinstellungen für Wiederholungstests konstant. Umbenennen oder Verschieben von Statements kann ihre Zufallsströme ändern.

Die Grenze für regelbasierte Wiederholbarkeit lautet:

Gleiche Engine-Version + gleiche vollständige deterministische Eingaben + gleicher expliziter Seed + gleiche Ausführungstopologie + gleiche deterministische Serialisierung und Reihenfolge → byte-identisches regelbasiertes Artefakt über Rechner und Zeit hinweg.

Das verspricht keine Byte-Kompatibilität zwischen 3.5 und 4.0. Eine geänderte Worker-Anzahl benötigt eine separate Prüfung für deine Quelle und Ausgabe. ML-Ausgaben fallen nicht unter diese Zusage für byte-identische regelbasierte Ausgaben.

Hashes und verknüpfte IDs

Relevant für dich, wenn: du Hash mit einem dritten Argument oder salt= verwendest, gespeicherte Hashes vergleichst oder gehashte IDs über Dateien, Felder oder Tabellen hinweg verknüpfst.

Was sich ändert und warum: Hash verwendet jetzt den Seed des Laufs und die Position des Feldes im Modell statt eines separaten Salt-Arguments. So steuert der Seed auch die Hashwerte, während unabhängige Felder getrennt bleiben. Diese Trennung passt nicht zu jedem Anwendungsfall: Brauchen zwei Tabellen gleiche IDs, kann getrenntes Hashing ihre Verknüpfung zerstören.

So migrierst du:

• Ersetze Hash('sha256', 'hex', 'old-salt') durch Hash('sha256', 'hex') und entferne auch benannte salt=-Argumente. Setze für Seed-basiertes Hashing rngSeed auf <setup>. Rechne mit anderen Hashwerten; alte Pseudonyme bleiben dadurch nicht erhalten.
• Prüfe sämtliche Verknüpfungen und gespeicherten IDs. Im selben Feld ergeben gleiche Eingaben bei gleichem Seed über Datensätze hinweg denselben Hashwert. Derselbe Wert und Seed garantieren an verschiedenen Feldpositionen jedoch nicht denselben Hashwert.
• Müssen mehrere Ausgaben eine ID teilen, berechne das Pseudonym einmal und verwende diese Zuordnung wieder. Stimme Zuordnung und Migration mit dem Projektverantwortlichen ab, bevor du verknüpfte Datenbestände ersetzt.
• Halte alte und neue pseudonymisierte Daten getrennt, bis ihre Verbraucher gemeinsam umgestellt sind. Überschreibe nicht einfach erwartete Hashes, damit ein Test wieder grün wird.

Ohne Seed verwendet Hash einen Hash ohne Schlüssel, der nur vom Eingabewert abhängt. Den Seed zu entfernen erhält weder den bisherigen Schutz noch die bisherigen Hashwerte. Ein Seed ersetzt auch keine Verwaltung geheimer Schlüssel. Die verfügbaren Argumente stehen in der Converter-Referenz.

Datumswerte und Gewichtsausdrücke

Aktuelle und relative Datumswerte

Relevant für dich, wenn: dein Modell datetime.now(), datetime.utcnow(), date.today() oder Generatorfenster relativ zur aktuellen Zeit verwendet.

Was sich ändert und warum: Läufe mit Seed verwenden eine feste Referenzzeit, damit ein Test nicht allein durch die Ausführung am nächsten Tag andere Ergebnisse liefert. Die Standardreferenz ist 01.01.2025 um 12:00:00 Uhr, nicht die aktuelle Rechnerzeit. Läufe ohne Seed verwenden die aktuelle Uhrzeit.

So migrierst du: Prüfe datumsabhängige Tests und Zeiträume. Benötigt dein Szenario ein bestimmtes fachliches Datum, gib einen Wert oder Zeitraum vor, statt now() als Ausführungsdatum zu verstehen. Beispielsweise legt DateTimeGenerator(value='2026-07-30 12:00:00') ein Szenariodatum fest. Benötigst du tatsächlich aktuelle Datumswerte, prüfe vor dem Entfernen des Seeds die Auswirkungen auf das gesamte Modell. Siehe Datums- und Zeitgenerierung.

Datums- und Zeitgewichte

Relevant für dich, wenn: hour_weights, minute_weights, month_weights oder ähnliche Argumente Python-Ausdrücke oder List Comprehensions enthalten.

Was sich ändert und warum: Gewichte werden jetzt als Zahlenlisten gelesen, nicht als Python-Code ausgeführt. Du kannst eine Liste direkt angeben, wiederholen oder Listen verbinden. So werden ungültige Gewichte erkannt, ohne Code auszuführen, nur um die Häufigkeit eines Werts festzulegen.

So migrierst du: Ersetze etwa den String '[1 for _ in range(24)]' durch '[1]*24'. Behalte die erforderliche Anzahl von Einträgen, nichtnegative Gewichte und mindestens ein positives Gewicht bei. Prüfe die resultierende Verteilung, nicht nur den Start des Generators.

XML-Attribute und Elementnamen

Relevant für dich, wenn: dein 3.5-Modell veraltete Attribute, Tippfehler oder type zur Auswahl eines Datenbestands enthält.

Was sich ändert und warum: XML-Elemente weisen unbekannte Attribute standardmäßig zurück. Ein Tippfehler erzeugt weiterhin einen Fehler, statt eine scheinbare Einstellung zu akzeptieren, welche die Engine ignoriert. Bekannte alte Attribute bleiben aus Kompatibilitätsgründen in der Grammatik: Beliebige alte Stringwerte auf diesen registrierten Attributen werden mit Warnung W004 ausgeführt und ignoriert. Kanonische typisierte Felder prüfen ihre Werte weiterhin; dokumentierte treiberspezifische Attribute bleiben Ausnahmen auf ihren Client-Deklarationen.

So migrierst du: Prüfe Element und Attribut aus der Fehlermeldung in der Modellreferenz. Häufige Änderungen sind:

Alte Eingabe	Änderung für 4.0
multiprocessing auf <setup>, <generate> oder <iterate>	Jeder alte Stringwert wird mit W004 akzeptiert und ignoriert. Optional entfernen; verwende numProcess für die Prozessanzahl und mpPlatform auf <generate> für die Multiprocessing-Startmethode. Der alte Wert ist keine Prozessanzahl.
<setup schemaVersion="…">	Jeder alte Stringwert wird mit W004 akzeptiert und ignoriert. Optional entfernen; die installierte Engine bestimmt die DSL-Version.
<operate template-dir="…">	Wird mit W004 akzeptiert und ignoriert. Optional entfernen; trage die richtige Template-Referenz in jede Steuerzeile ein.
<nestedKey source="mem" type="orders">	Alias für sourceEntity="orders"; wird mit Warnung W006 akzeptiert, damit ein falsch geschriebenes list oder dict sichtbar wird. Umschreiben, wenn es passt. type für list oder dict behalten. Ein ausdrücklich anderes sourceEntity bleibt ein Fehler, andere Source-Typen bleiben strikt validiert.
<ama-generate variable_prefix="…" variable_suffix="…">	Alias für variablePrefix/variableSuffix; wird ohne Warnung akzeptiert. 3.5 ignorierte die Snake-Case-Schreibweise und nutzte den Default __; 4.0 wendet den Wert an. Prüfe deshalb Modelle mit einem anderen Präfix oder Suffix.
Object-Storage type="s3"	Den unterstützten Wert type="aws" verwenden. Die alte Schreibweise war kein funktionierender S3-Clienttyp.

Unbekannte Attribute und ungültige Werte kanonischer typisierter Felder bleiben Fehler. W004 gilt nur für die oben genannten registrierten alten Attribute; ihre alten Stringwerte werden akzeptiert und ignoriert. Jeder Stringwert von <ml-train mode>, auch persist, wird mit W004 akzeptiert und ignoriert; er steuert keine Persistenz. Entferne ihn, wenn es passt.

Entferne unterstützte Aliase nicht allein wegen ihres Alters. Beispielsweise bleiben type="integer", die Datenbankwerte postgres/sqlserver und mpPlatform="multiprocessing" erlaubt. Unter Erhaltene Kompatibilität findest du Formen, die weiter ausgeführt, für neue Modelle aber nicht mehr vorgeschlagen werden.

Memstore: Schreiben und Lesen mit mem

Relevant für dich, wenn: dein Modell <memstore> deklariert oder erzeugte Datensätze in einem späteren Schritt desselben Laufs wiederverwendet. Nutzt du bereits target="mem" und source="mem" ohne separate Deklaration, musst du nichts ändern.

Was sich ändert und warum: Die alte eigenständige <memstore>-Deklaration hatte bereits in der 3.5-Runtime keine Wirkung. Ein altes <memstore id="…"/>-Kindelement mit erforderlicher, gültiger id bleibt mit Warnung W005 akzeptiert und wird ignoriert, damit bestehende Modelle nicht allein für die Ausführung unnötig geändert werden müssen. Die Deklaration erzeugt keine eigene Client-, Source- oder Target-ID. Entferne sie, wenn es passt; der eingebaute Memstore-Workflow bleibt unverändert: Daten einmal erzeugen und in späteren Schritten wiederverwenden, ohne dafür eine Datei zu exportieren und erneut einzulesen.

So migrierst du: Das Entfernen der Deklaration ist optionale Bereinigung. Behalte die Schritte zum Erzeugen und Wiederverwenden deiner Daten. Verwende mem als eingebauten Namen für Quelle und Ziel:

Einstellung	Bedeutung
target="mem"	Erzeugte Datensätze in den Memstore schreiben.
name="customers"	Sie standardmäßig unter customers speichern. Ein explizites targetEntity ändert diesen Namen.
source="mem"	Aus dem Memstore lesen.
sourceEntity="customers"	Den gespeicherten Datenbestand customers auswählen. Hast du beim Schreiben targetEntity gesetzt, verwende stattdessen diesen Namen.

Die id der alten Deklaration ist nicht der Produktname. Setze den Produktnamen bei Bedarf am erzeugenden targetEntity und am lesenden sourceEntity. Eine fehlende oder ungültige alte id bleibt ein Fehler.

mem ist der eingebaute Name, kein automatisch gewähltes Ausgabeziel bei fehlendem target. Gib das Ziel ausdrücklich an und platziere den erzeugenden Schritt vor dem lesenden Schritt.

Dieses vollständige Beispiel speichert zwei Kunden, liest sie wieder ein und zeigt sie im Task-Log:

<setup numProcess="1">
  <generate name="customers" count="2" target="mem">
    <key name="customer_id" generator="IncrementGenerator"/>
    <key name="status" constant="active"/>
  </generate>
  <generate name="customer_copy" source="mem" sourceEntity="customers"
            distribution="ordered" target="LogExporter"/>
</setup>

Ergebnis prüfen: customer_copy enthält dieselben zwei Kunden, mit den IDs 1 und 2 und dem Status active. Memstore-Daten gehören zu diesem Lauf. Benötigt ein anderer Lauf sie, exportiere sie in eine Datei oder Datenbank. LogExporter dient hier nur zur Kontrolle des kleinen Beispiels.

Gewichtete Entity-Quellen

Relevant für dich, wenn: der Name einer Quelldatei auf .wgt.ent.csv endet.

Was sich ändert und warum: .wgt.ent.csv bedeutet jetzt durchgängig, dass Zeilen nach ihren Gewichten ausgewählt werden. Du musst die Gewichtsspalte und die gewünschte Anzahl angeben. So wird eine gewichtete Datei nicht wie eine gewöhnliche Liste gelesen, bei der die gewünschte Auswahlhäufigkeit verloren geht.

So migrierst du:

1. Ergänze auf <generate> weightColumn="sample_weight" und ersetze sample_weight durch den tatsächlichen Spaltennamen. <variable> und <reference> verwenden wie in 3.5 die Spalte weight als Default; setze weightColumn nur, wenn deine Spalte anders heißt.
2. Ergänze count auf <generate>; die Anzahl darf nicht aus der Zeilenanzahl der Datei abgeleitet werden. count="100" fordert beispielsweise 100 Auswahlen an.
3. Verwende distribution="weighted" oder lasse das Attribut für den gewichteten Default weg. Entferne cyclic="true" und unique="true"; gewichtete Auswahl erlaubt wiederholte Zeilen.
4. Prüfe, dass nachgelagerte Anwendungen die Gewichtsspalte nicht als Ausgabefeld benötigen: Sie steuert nur die Auswahl und wird danach entfernt.

War nie eine gewichtete Auswahl beabsichtigt, benenne die Datei in .ent.csv um, passe die Verweise an und prüfe ihre Spalten. Ergänze keine beliebigen Gewichte, nur um einen Validierungsfehler zu beseitigen.

Begrenzte Quellen und unterstützte Optionen

Kafka-Eingaben und ML-Modellquellen

Relevant für dich, wenn: ein <generate> Kafka-Nachrichten oder ein ML-Modell liest und bisher Selektoren, Cyclic-/Unique-Auswahl oder eine andere Verteilung als ordered verwendet hat.

Was sich ändert und warum: Diese Quellen melden jetzt Fehler für nicht unterstützte Optionen, statt sie zu ignorieren. So sieht ein Modell nicht länger so aus, als würde es filtern oder Duplikate entfernen, obwohl es das nicht tut. Kafka liefert einen Nachrichtenstrom; deshalb musst du auch begrenzen, wie viele Nachrichten ein Generierungsschritt liest.

So migrierst du:

• Setze für Kafka ein positives count für die gewünschte Anzahl, beispielsweise count="100". Das ist die einfachste Migration. Auch berechnete Anzahlen und minCount/maxCount werden unterstützt. count="0" fordert keine Datensätze an.
• Setze für ML-Quellen count oder begrenze die Anzahl mit maxCount.
• Lasse distribution weg oder verwende distribution="ordered". Entferne selector, iterationSelector, cyclic="true" und unique="true". Ein explizites false aktiviert die nicht unterstützte Funktion nicht.
• War Filterung oder Deduplizierung beabsichtigt, setze sie in den vorgelagerten Daten/Topics oder in der Trainingsdatenaufbereitung um. Das Entfernen einer ignorierten Option ergänzt nicht das ursprünglich gewünschte Verhalten.

Kafka-Reihenfolge bleibt partitionslokal; ordered verspricht keine globale Reihenfolge über Partitionen hinweg. RabbitMQ ist neu in 4.0, seine Einrichtung ist daher keine Migration bestehender 3.5-Modelle.

Kafka- und ML-Konfigurationswerte

Relevant für dich, wenn: die Validierung eine bisher ungeprüfte Kafka- oder ML-Option zurückweist.

Was sich ändert und warum: Unterstützte Werte und numerische Grenzen werden vor dem Start geprüft. Ungültige Einstellungen führen dadurch nicht erst später zu Client- oder Trainingsfehlern.

So migrierst du: Verwende die zulässigen Werte aus der Modellreferenz. Kafka acks="2" ist beispielsweise ungültig; wähle 0, 1 oder all nach dem benötigten Bestätigungsverhalten. ML batchSize="0", negatives samplingTopP und trainValSplit über 1 sind ungültig. Wähle einen gültigen Wert passend zum beabsichtigten Training, statt wahllos einen Default zu übernehmen. Bereits gültige Einstellungen bleiben unverändert.

Delete, Clear und Drop

Relevant für dich, wenn: ein Modell ein Datenbankziel mit .delete verwendet, insbesondere zum Bereinigen einer ganzen Tabelle oder Collection.

Was sich ändert und warum: Einzelne Datensätze löschen, eine Tabelle leeren und eine Collection entfernen sind jetzt getrennte Operationen. So lassen sich gefährliche Schritte leichter prüfen. Dieselbe Datenbanktabelle seitenweise zu lesen und dabei zu löschen wird zurückgewiesen: Durch Löschungen verschieben sich Zeilen zwischen Seiten, sodass Datensätze übersprungen werden können.

So migrierst du: Entscheide zuerst, welche Operation beabsichtigt ist.

Absicht	Target und Modellform
Ausgewählte Datensätze löschen	.delete mit expliziter Auswahl beibehalten. Bei MongoDB einen nichtleeren Filter verwenden.
Alle Zeilen/Dokumente entfernen, Tabelle/Collection behalten	.clear mit targetEntity verwenden.
Eine MongoDB-Collection entfernen	.drop mit targetEntity verwenden. RDBMS .drop wird nicht unterstützt.

Führe .clear und .drop einmal auf der Root-Ebene von <setup> aus. Entferne Quelle, Selektor, Count, Kindelemente und zusätzliche Targets aus dieser Operation. Diese Operationen zerstören Daten. Teste sie nur an einem entbehrlichen Ziel mit Wiederherstellungsplan.

Zum Löschen ausgewählter Datensätze in relationalen Datenbanken lies die Schlüssel aus einer separaten Hilfstabelle oder speichere sie vor dem Löschen separat. Zwei Client-IDs für dieselbe tatsächliche Quelltabelle umgehen die Einschränkung nicht. Auch komplexe Selektoren mit nicht eindeutig bestimmbarer Quelltabelle können zurückgewiesen werden; verwende eine einfache, eindeutig angegebene Hilfsquelle.

Einige alte Bereinigungsformen laufen mit Warnung W003 weiter, aber nur unter Bedingungen. Sie müssen auf Root-Ebene liegen, genau ein Target, kein Script und keine Kinder haben. targetEntity ist erforderlich, sofern kein statisches MongoDB-find das Ziel liefert. Fehlende oder mehrdeutige Selektoren erlauben kein Leeren von Daten. Bevorzuge beim Bearbeiten die explizite Form.

Template-Verarbeitung und Exportziele

Relevant für dich, wenn: dein Modell <operate> enthält, insbesondere wenn FORCE_LOCAL_EXPORT den Ausgabeort bestimmte oder Steuerzeilen kein Template angegeben haben.

Was sich ändert und warum: Das Modell bestimmt jetzt, wohin Dateien geschrieben werden; FORCE_LOCAL_EXPORT leitet sie nicht mehr um. Du kannst das Ziel direkt im Modell prüfen. Fehlende Template-Verweise und nicht unterstützte Formate melden jetzt Fehler. So fallen unvollständige Ausgaben auf, statt als erfolgreiche Lieferung zu gelten.

So migrierst du:

• Wähle export_strategy="local", um neben dem Descriptor zu schreiben. Das ist der neue Default. Prüfe den Ausgabeort deshalb auch, wenn dein Modell bisher kein export_strategy gesetzt hat.
• Wähle export_strategy="minio" nur mit genau einem konfigurierten MinIO-Client und einem Bucket. Verlasse dich nicht mehr auf FORCE_LOCAL_EXPORT.
• Ersetze export_strategy="s3" durch ein unterstütztes Ziel oder einen separat unterstützten Object-Storage-Exportablauf. Der alte Wert wurde akzeptiert, implementierte aber keine AWS-S3-Auslieferung.
• Gib jeder nichtleeren Steuerzeile eine Template-Referenz mit Endung .xml oder .json. Eine fehlende Template-Zelle oder eine nicht unterstützte Endung ist auch bei einer Warnungsstrategie ein Konfigurationsfehler.
• Unterscheide davon eine benannte, aber nicht auffindbare Template-Datei: Dafür gilt weiterhin template_not_found_action. Prüfe Dateipfade und Warnungen vor der Abnahme der Ausgabe.

AMA-Deklarationen und Referenzen

Relevant für dich, wenn: dein Modell <ama-generate> mit Profilen, Templates, Outputs oder Packages nutzt.

Was sich ändert und warum: Profil- und Template-IDs müssen eindeutig sein. Jeder Verweis muss auf eine vorhandene Definition zeigen. Fehlende oder widersprüchliche Einstellungen fallen damit vor der Ausgabe auf und lassen sich leichter finden.

So migrierst du: Vergib eindeutige IDs für Profile und Templates, löse jede Profil-/Template-Referenz auf und wähle pro Output genau eines von type oder messageType. Behalte höchstens ein Package mit type="zip". Entferne unbekannte Attribute und vergleiche die erzeugten Artefakte mit der erwarteten Menge. Die Attribute jedes Kindelements findest du in der Modellreferenz.

Template-Tokens: 3.5 ignorierte Monats- und Jahres-Offsets in {Date: offset=…}; +P3M20D oder -P30Y lieferten deshalb das aktuelle Datum. {IK: prefix=…} blieb unaufgelöst in der Ausgabe stehen. 4.0 wendet ISO-8601-Dauern mit Kalendermonat-Arithmetik an und löst {IK: prefix=NN} zum zweistelligen Präfix mit sieben Ziffern auf; ein anderes Präfix bleibt sichtbar stehen. Eine nicht unterstützte Dauer bleibt sichtbar in der Ausgabe stehen, statt zum heutigen Datum zu werden. Vergleiche Datumswerte und IK-Werte in AMA-Ausgaben mit deinen Referenzdateien.

Datensatzanzahl und Ausgabedateien

Zyklische Datenbankabfragen

Relevant für dich, wenn: du cyclic="true" mit einer Datenbankquelle nutzt und mehr Datensätze anforderst, als die Quelle enthält.

Was sich ändert und warum: Der Quell-Snapshot wird bis zur angeforderten Anzahl wiederholt, statt still weniger Datensätze zu liefern. Das angeforderte Testvolumen wird damit tatsächlich erreicht. Dabei können Wiederholungen entstehen, die deine alte Referenzausgabe nicht enthielt.

So migrierst du: Vergleiche Anzahl und erwartete Duplikate. Behalte cyclic, wenn Wiederholung gewünscht ist. Entferne es andernfalls und wähle eine von der Quelle unterstützte Anzahl. Reduziere den Count nicht automatisch, wenn das größere Testvolumen die ursprüngliche Anforderung war.

Vollständige Company-Entity

Relevant für dich, wenn: ein Modell die vollständige Company-Entity exportiert oder vergleicht statt einzelner Felder.

Was sich ändert und warum: Die vollständige Ausgabe enthält jetzt legal_form, das bereits als company.legal_form verfügbar war. Die Entity-Referenz listet dieselben Felder, die der Export schreibt.

So migrierst du: Ergänze legal_form in Referenzdateien und in nachgelagerten Schemas, die die ganze Entity lesen. Modelle, die einzelne Felder auswählen, sind nicht betroffen.

Kollisionen statischer Einzeldatei-Ausgaben

Relevant für dich, wenn: mehrere Root-Generate-Stufen, auch über Includes, JSONSingle, XMLSingle oder TemplateSingle mit demselben aufgelösten statischen Namen schreiben.

Was sich ändert und warum: Eine spätere kollidierende Stufe wird vor dem Schreiben zurückgewiesen. Das schützt frühere Ausgaben vor Überschreiben.

So migrierst du: Gib unabhängigen Lieferungen unterschiedliche Namen oder Exportpräfixe/-suffixe/-orte. Prüfe die resultierenden Dateinamen in nachgelagerten Jobs. Die Prüfung ist kein allgemeiner Überschreibschutz: Ausgaben mit targetEntity-Routing sind ausgenommen. Deren Ziele musst du weiterhin selbst prüfen.

Erhaltene Kompatibilität

Diese Formen musst du nicht allein für die Ausführung unter 4.0 umschreiben. Bevorzuge beim Bearbeiten die klarere Form:

Akzeptierte Runtime-Form	Bevorzugte Form und Grund
<variable source="mem" type="orders">	sourceEntity="orders" trennt Entity-Auswahl und skalaren type. Die alte Form wird vom Editor-/Authoring-Vertrag nicht mehr vorgeschlagen.
<nestedKey source="mem" type="orders">	Alias für sourceEntity="orders"; wird mit Warnung W006 akzeptiert. type für list oder dict behalten. Widersprüchliche explizite sourceEntity-Werte bleiben Fehler.
<ml-train mode="...">	Jeder alte Stringwert wird mit W004 akzeptiert und ignoriert. Wenn es passt, entfernen; der Wert steuert keine Persistenz.
schemaVersion auf <setup>	Jeder alte Stringwert wird mit W004 akzeptiert und ignoriert. Wenn es passt, entfernen; die installierte Engine bestimmt die DSL-Version.
multiprocessing auf <setup>, <generate> oder <iterate>	Jeder alte Stringwert wird mit W004 akzeptiert und ignoriert. Wenn es passt, entfernen; für Parallelität numProcess und mpPlatform verwenden.
<operate template-dir="…">	Wird mit W004 akzeptiert und ignoriert. Wenn es passt, entfernen; die Template-Referenz in jeder Steuerzeile verwenden.
<setup><memstore id="…"/></setup>	Wird mit W005 und gültiger id akzeptiert und ignoriert. Wenn es passt, entfernen; target="mem", source="mem" und sourceEntity weiterverwenden.
<ama-generate variable_prefix="…" variable_suffix="…">	Bevorzuge variablePrefix/variableSuffix; die Snake-Case-Form ist ein Alias dafür und wird ohne Warnung akzeptiert.
<iterate> mit Target	<generate> für eine Stufe verwenden, die Ausgabe erzeugt/exportiert. Runtime-Kompatibilität bleibt bestehen; Authoring reserviert iterate für Quelldurchlauf ohne Target.
Unterstützte alte Bereinigungsformen	Der Warnung W003 folgen und wie oben beschrieben explizit auf .clear/.drop umstellen.

Python-Erweiterungen

Relevant für dich, wenn: du eigene Python-Generatoren pflegst oder EE-Implementierungsmodule direkt importierst. Reine XML-Projekte können diesen Abschnitt überspringen.

Was sich ändert und warum: Eigene Generatoren verwenden jetzt denselben Zufallskontext wie die eingebauten Generatoren. Dadurch können auch ihre Werte dem Seed des Laufs folgen. Einige alte Konstruktorargumente und interne Imports entfallen; Erweiterungen, die sie verwenden, müssen angepasst werden.

So migrierst du: Prüfe entfernte seed-/rng-/seeded_mode-Konstruktorargumente und Imports wie alte RNG-Helfer gegen die aktuelle Generatorreferenz. Verwende bind(...)/generate(rng_ctx), wenn deine Erweiterung den Zufallskontext des Laufs benötigt. Ein alter eigener generate(self) bleibt aufrufbar; nicht jede Erweiterung braucht eine neue Signatur. Dass ein alter Aufruf akzeptiert wird, beweist keine deterministische Ausgabe. Führe die Tests deiner Erweiterung vor dem Deployment mit der 4.0-Abhängigkeit aus.

Das migrierte Projekt prüfen

1. Validiere das bearbeitete XML in IDE oder Platform und korrigiere nicht unterstützte Attribute/Optionen.
2. Starte eine kleine Datenmenge gegen isolierte Testziele. Prüfe Warnungen ebenso wie Fehler.
3. Kontrolliere Datensatzanzahl, Pflichtfelder, eindeutige IDs, tabellenübergreifende Beziehungen, Datumswerte und Ausgabepfade.
4. Wiederhole Replay-Tests mit denselben vollständigen Eingaben und demselben Seed. Trenne ML-Qualitätsprüfungen von exakten Ausgabevergleichen.
5. Übernimm neue Referenzausgaben erst nach bestandenen fachlichen Prüfungen. Behalte altes Projekt und alte Daten, bis abhängige Verbraucher die Migration abgenommen haben.

Ändert eine Migration gemeinsame Pseudonyme, destruktive Operationen oder eine eigene Erweiterung mit unklarem Vertrag, stimme das erwartete Verhalten vor dem Rollout mit deinem DATAMIMIC-Projektkontakt ab.