#534 - Remap foreign keys when restoring plan versions

[brijesh-amin]

Summary

• remap dependent foreign keys when restoring plan versions
• add transaction regression coverage

Verification

• Existing transaction tests updated for restore behavior

Closes #534

[Copilot]

Pull request overview

This PR updates Plan.restoreVersion() to correctly remap parent/child foreign keys when recreating a plan hierarchy from a snapshot, preventing restored child rows from pointing at obsolete snapshot IDs. It also adds a regression test to validate remapping for several hierarchy tables.

Changes:

• Remap restored pasture → plant community → indicator/monitoring area/purpose/action foreign keys to newly created parent IDs during restoreVersion().
• Remap schedule entries to the newly created schedule ID and the newly created pasture ID.
• Add a transaction regression test asserting restored hierarchy children link to their new parents.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/libs/db2/model/plan.ts	Implements FK remapping during restore across hierarchy models and schedule entry creation.
tests/api_v1/plan.restore-version.transaction.spec.js	Adds regression coverage for restored hierarchy child FK remapping.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[brijesh-amin]

Addressed review feedback in commit 077a7f3:

• Added an explicit 400 error when a schedule entry references a pasture that was not restored.
• Extended the restore regression test with a grazing schedule and entry. It now asserts the restored entry references the newly created schedule and pasture IDs.

Build and lint pass. The integration test was not run because the configured myra_test database is unavailable; no database-backed command was executed.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

tests/api_v1/plan.restore-version.transaction.spec.js:210

• This regression test lives in the transaction spec but calls Plan.restoreVersion directly, bypassing the controller’s db.transaction().execute(...) wrapper (see PlanVersionController.ts:99-101). Wrapping the call in a transaction (or using the restore endpoint) will keep the test aligned with the suite intent and catch transaction-related regressions.

    await Plan.restoreVersion(db, 1, 1);

src/libs/db2/model/plan.ts:388

• newPastures.find(...) runs a linear search for every schedule entry, which can become O(pastures × entries) for larger plans. Consider building a lookup map once (originalPastureId → newPastureId) and using it for constant-time remaps inside the entry loop.

              if (!scheduleEntryCreator) return null;
              const originalPastureId = entry.pastureId ?? entry.pasture_id;
              const newPasture = newPastures.find((pasture) => pasture.original.id === originalPastureId);
              if (!newPasture) {
                throw errorWithCode(