Description
In one of our custom projects, we noticed an issue with adding the Energy EMS extension.
Flyway was throwing errors because of an "out of order" SQL migration script.
The flyway_schema_history table showed the most recent migration being from March 2026,
while the energy extension introduced a new migration script that was from February 2026.
This caused the instance to fail, and not boot up correctly.
The temporary solution for this is to add the OR_DB_FLYWAY_OUT_OF_ORDER = true environment variable.
Although I'm not sure whether this suits as a permanent fix...
This leads to a bigger discussion: "How do we handle SQL migration scripts, when extensions get added after the fact?"
Do we automatically allow out of order migration scripts? Is it possible to isolate these extension-specific migrations?
I guess this is open for discussion.
Description
In one of our custom projects, we noticed an issue with adding the Energy EMS extension.
Flyway was throwing errors because of an "out of order" SQL migration script.
The
flyway_schema_historytable showed the most recent migration being from March 2026,while the energy extension introduced a new migration script that was from February 2026.
This caused the instance to fail, and not boot up correctly.
The temporary solution for this is to add the
OR_DB_FLYWAY_OUT_OF_ORDER = trueenvironment variable.Although I'm not sure whether this suits as a permanent fix...
This leads to a bigger discussion: "How do we handle SQL migration scripts, when extensions get added after the fact?"
Do we automatically allow out of order migration scripts? Is it possible to isolate these extension-specific migrations?
I guess this is open for discussion.