A version ID is a string attached to DSL content, typically a serialized AST, identifying the Domain IDE structure version it conforms to. Annotating persisted content lets the IDE decide whether it can safely load and project that AST. section 10.3.1 section 10.4
Compare the content’s version ID with the currently running Domain IDE whenever the AST is loaded:
- Matching IDs allow normal projection or further processing. section 10.3.1
- A newer content version requires an outdated IDE to refuse loading it. section 10.3.1
- An older content version may require an AST migration before use. section 10.3.1 section 10.3.2
The check applies in the backend when JSON is deserialized, in the frontend after transmission, and in the code generator after retrieval. These checks prevent version mismatches from corrupting DSL content. section 10.3.1
AST migrations use a “from” version ID and a “to” version ID. Run a migration only when the AST matches its source version, then update the content to the destination version. section 10.3.2 section 10.4
Migrating a renamed concept and property
A migration can transform the Data Attribute concept into Attribute, copy the initial value property to value, and remove the old property. The resulting AST receives the migration’s destination version ID. section 10.3.2
Listing 10.1 The implementation of an AST migration
const { isAstObject } = require("../common/ast")
const modifyDataAttribute = (value) => {
if (isAstObject(value)) {
const { settings } = value
for (const propertyName in settings) {
modifyDataAttribute(settings[propertyName])
}
if (value.concept === "Data Attribute") {
value.concept = "Attribute" #1
settings["value"] =
settings["initial value"] #2
delete settings["initial value"]
}
}
if (Array.isArray(value)) {
value.forEach(modifyDataAttribute)
}
}
module.exports.modifyDataAttribute = modifyDataAttribute
Inspect the depth-first AST migration implementation that recursively modifies nested objects and arrays. section 10.3.2
