You can run model-defined post-deployment actions once in every MDrivenServer database by adding actions to the unrooted SysScriptAfterEvolve ViewModel. Use this pattern when a database evolve changes the model and you must also correct, move, or initialize data in each deployed environment.
What ScriptAfterEvolve does
A database evolve updates the database schema to match the current model. Some deployments also require data work that is not part of the schema change. For example, after moving a setting to a new location in the model, you may need to copy existing values; after adding a value store or setting, you may need to initialize it.
You can perform this work manually with the OCL debugger, but manual work can be missed or performed differently across development, test, acceptance, and production environments. ScriptAfterEvolve makes the work part of the model deployment pattern handled by MDrivenServer.
After an evolve, MDrivenServer checks the action columns in the unrooted SysScriptAfterEvolve ViewModel. For each action column that has not previously been logged in that database, MDrivenServer executes the action and records it in SysScriptAfterEvolveActionLog.
How once-only execution works
The action column name is the action's identity. MDrivenServer uses that name as the value of SysScriptAfterEvolveActionLog.ColumnNameKey.
- MDrivenServer completes an evolve.
- It checks each action column in SysScriptAfterEvolve.
- For an action column whose name is not present in SysScriptAfterEvolveActionLog.ColumnNameKey, it executes the action.
- It creates a SysScriptAfterEvolveActionLog entry with the action column name as ColumnNameKey.
- On later evolves of the same database, an action whose column name is already logged is not executed again.
This means an action runs once per database, not once across all environments. For example, an action called InitializeNewSetting runs in the development database when that database evolves, and also runs independently when the test and production databases evolve.
Create a post-evolve action
- In MDriven Designer, create an unrooted ViewModel named SysScriptAfterEvolve.
- Add an action column for each post-evolve task you need.
- Give every action column a stable, descriptive name. The exact column name becomes the log key used to determine whether the action has already run.
- Define the action to perform the required data correction or initialization. Use Actions Editor guidance when working with actions, and use OCL where the action requires model logic.
- Deploy the model to MDrivenServer and let the database evolve.
- Verify that the expected action has an entry in SysScriptAfterEvolveActionLog. Review the recorded result, execution time, and any error information.
Example: initialize data after adding a setting
Assume a model change adds a setting that existing installations do not yet have. Create an action column named InitializeDefaultSetting in SysScriptAfterEvolve and define that action to create or initialize the required setting data.
When the model is evolved in a database for the first time, MDrivenServer executes InitializeDefaultSetting and logs that column name. A later evolve of the same database does not execute that action again. When the same model reaches another environment, that environment has no corresponding log entry yet, so the action executes there once.
Use a new action-column name for a new deployment task. Do not rename an already executed action column unless you intend the renamed action to be treated as a new action in each database.
Execution log
MDrivenServer records post-evolve execution in the SysScriptAfterEvolveActionLog class.
| Attribute | Purpose |
|---|---|
| ColumnNameKey : String | The name of the action column in SysScriptAfterEvolve. MDrivenServer uses this value to determine whether that action has already been handled in the current database. |
| Expression : Text | The expression associated with the logged action. |
| Result : String | The result recorded for the action execution. |
| Performed : DateTime | The date and time recorded for the execution. |
| Error : String | Error information recorded for the action, if any. |
Review this log after deployment, particularly when an action performs a data migration or initialization. The log is the database-specific record of which action columns MDrivenServer has processed.
Deployment behavior and maintenance
You can leave old action columns in SysScriptAfterEvolve. They do not run again in a database where their column names have already been logged.
You can also skip intermediate model generations and evolve directly to the current model. MDrivenServer checks all action columns in the current SysScriptAfterEvolve ViewModel; action columns that have not yet been logged in that database execute and are logged.
Keep each action focused on one deployment task. For example, use separate action columns for copying existing data and initializing a new setting. This gives each task its own log key and makes deployment verification clearer.
Use with automated deployment
ScriptAfterEvolve is intended for deployments where data work must accompany an evolve. It removes the separate manual step of doing "a few things once deployed" in each environment.
For an automated build, code-generation, rebuild, upload, evolve, and deployment flow, see Documentation:ContinuousIntegration. ScriptAfterEvolve handles the model-defined post-evolve work; CI handles automation of the surrounding deployment process.
If an evolve itself fails or the server's current evolve script is missing, resolve that issue before relying on post-evolve actions. See Documentation:MDriven Server problem with evolve.