mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-07-31 04:12:10 +03:00
5f365bae7c
The runner reads exactly one directory and records the bare numeric prefix as the version, so the numeric slots are a single global namespace. Any distribution that ships its own migrations next to the upstream set has to draw from that same range while upstream keeps appending to it — and when both sides claim a number, the runner records one name for it and treats the other as already applied. That migration then never runs, silently, on every already-provisioned database. OMNIROUTE_EXTRA_MIGRATIONS_DIRS registers additional directories as `namespace=dir` entries separated by the platform path delimiter. Files found there are recorded as `<namespace>-<number>` (e.g. `ee-134`), a version space that cannot collide with the upstream numeric one, and they are applied after the core set. Unset — the default, and the only case for a plain install — nothing changes: no filesystem access, identical behaviour. Misconfiguration throws instead of being skipped. A malformed entry, a namespace outside [a-z][a-z0-9]*, a duplicate namespace, or a directory that does not exist aborts startup, because silently missing schema is the exact failure this exists to prevent. Two files sharing a number inside the SAME namespace still collide and throw, mirroring the runner's own guard. Also fixes an inconsistency the tests surfaced: a missing core directory returned early and took the extra directories down with it. They are an independent set. The version-namespaced strings need no further plumbing — the applied set, the gap reconciliation and the name-mismatch check all key on the version string, and the numeric-only paths (`Number.parseInt`, the "032"/"041"/"042" special cases, `isSchemaAlreadyApplied`) ignore them by construction. 11 new tests; the 7 neighbouring migration suites stay green (62 tests).