chore(migrations): renumber 108_add_backup_paths to 109 to avoid upstream collision
upstream/beta independently shipped 108_seed_sl_email_template_translations.js
(Slovenian email template translations) using the migration number
this branch had already claimed for 108_add_backup_paths.js. Knex's
filename-based ordering would have caused both to attempt the slot
at merge time.
Renamed via `git mv` so file history is preserved. All five
references updated in lockstep:
- backend/src/services/_backupPathsBoot.js (require + comments)
- backend/src/services/backupService.js (LEGACY_BACKUP_PATHS comment)
- 3 integration test files (require + "migration 108" prose)
- migration's own header comment, with a paragraph explaining the
rename so reviewers don't wonder why the number jumped
**No data-migration impact for installs that already ran the
108-named version** (Ralf's beta, primarily): the migration's body
is idempotent — createTable is guarded by `hasTable`, and the seed
uses `onConflict('path').ignore()`. So when 109 runs against an
install whose backup_paths table is already populated, both the
schema step and the seed step no-op cleanly. The orphaned
`108_add_backup_paths.js` row in the `migrations` tracking table
sits harmlessly alongside the new `109_add_backup_paths.js` row.
No data lost, no double-insert, no schema drift. Mechanical rename
ahead of the PR opening.
This commit is contained in:
+9
-1
@@ -1,5 +1,13 @@
|
||||
/**
|
||||
* Migration 108 — config-driven backup walker.
|
||||
* Migration 109 — config-driven backup walker.
|
||||
*
|
||||
* (Originally numbered 108 on bugfix/crm-backup. Renumbered to 109
|
||||
* before merge because upstream/beta independently shipped
|
||||
* 108_seed_sl_email_template_translations.js. The createTable is
|
||||
* idempotent via `hasTable` guard and the seed uses
|
||||
* `onConflict('path').ignore()`, so beta installs that ran the
|
||||
* 108-named version of this file get a harmless no-op when 109
|
||||
* runs against the already-seeded table.)
|
||||
*
|
||||
* Stage B of the three-stage backup-hardening plan. The file-backup
|
||||
* walker (`getFilesToBackupInternal` in backupService.js) historically
|
||||
Reference in New Issue
Block a user