ReleaseReturn
Corex\Config\Releases\ReleaseReturn · class · Config layer
Going back to the release before (spec 107, US4; FR-040 to FR-045; plan D9, D10, D19). The folders the last installation moved out are moved back, by the swap’s own journal read backwards. That is all of it: no change to the database is reversed, and the copies of the tables are left for a person to read from. The release gone back to runs on the tables as the newer one left them. There are two ways back and they end the same. From the Releases screen, which is this. And through the recovery link, which runs without CoreX and so cannot tell CoreX it did: the screen finds that out when it is next opened, and puts its record right.
Public API
Section titled “Public API”__construct(ReleaseStore $store, ReleaseSwap $swap, ReleaseJournal $journal, ReleaseStaging $staging, ReleaseSafeguards $safeguards, InstalledRelease $installed, ReleaseTableCopies $copies, ReleaseRecord $record, ReleaseSteps $steps)
Section titled “__construct(ReleaseStore $store, ReleaseSwap $swap, ReleaseJournal $journal, ReleaseStaging $staging, ReleaseSafeguards $safeguards, InstalledRelease $installed, ReleaseTableCopies $copies, ReleaseRecord $record, ReleaseSteps $steps)”kept(): ?array
Section titled “kept(): ?array”The release that can be gone back to, or none.
goBack(string $phrase, int $actorId, DateTimeImmutable $now): array
Section titled “goBack(string $phrase, int $actorId, DateTimeImmutable $now): array”Put the previous release’s folders back.
takeInOneMadeByTheLink(DateTimeImmutable $now): bool
Section titled “takeInOneMadeByTheLink(DateTimeImmutable $now): bool”Take in a return that was made through the recovery link (FR-045). The link’s plugin moved the folders back and marked the journal, and could do no more: it uses nothing of CoreX. A journal that says “undone” beside a recovery plugin that is still there is that. A return made from the screen removes the plugin.