Updated Proposal: application schema coordination and versioning (markdown)

Richard Newman 2016-10-19 10:30:39 -07:00
parent d30f7508ed
commit 5f0cd6d47c

@ -200,7 +200,9 @@ Most migrations will be very simple — some per-fragment pre- or post-upgrade c
For example, an imaginary upgrade sequence for developers who made a bunch of errors in a previous release might be:
> From: page=2, save=1
>
> To: page=3, save=2
>
> - App 'pre': clean up old history so we don't have to fix it.
> - Page 'pre': fix duplicate visits, prior to imposing a uniqueness constraint.
> - Save 'pre': delete saves for pages that no longer exist, prior to imposing a component constraint.
@ -215,7 +217,9 @@ For example, an imaginary upgrade sequence for developers who made a bunch of er
Note that the page and save pre/rename/upgrade/post sequences are independent of each other and of the app sequence. Another application might share the page logic and perform this sequence first:
> From: page=2
>
> To: page=3
>
> - App 'pre': clean up old history so we don't have to fix it.
> - Page 'pre': fix duplicate visits, prior to imposing a uniqueness constraint.
> - Page renames: none.
@ -226,7 +230,9 @@ Note that the page and save pre/rename/upgrade/post sequences are independent of
leaving our first application to only upgrade the save schema fragment:
> From: save=1
>
> To: save=2
>
> - Save 'pre': delete saves for pages that no longer exist, prior to imposing a component constraint.
> - Save renames: rename `:save/instant` to `:save/savedAt` to fix a copy-paste error.
> - Save schema upgrade, 1->2: set `isComponent` to `true` to avoid orphans when history is deleted.