add lists of operations

This commit is contained in:
James Bardin 2020-07-01 16:58:56 -04:00
parent dcf62ed378
commit 1c1782bb1b
1 changed files with 46 additions and 1 deletions

View File

@ -32,6 +32,11 @@ digraph create {
}
-->
Order of operations:
1. `A` is created
1. `B` is created
1. `C` is created
## Resource Updates
An existing resource may be updated with references to a newly created
@ -52,6 +57,11 @@ digraph update {
}
-->
Order of operations:
1. `A` is created
1. `B` is created
1. `C` is created
## Simple Resource Destruction
The order for destroying resource is exactly the inverse used to create them.
@ -74,13 +84,16 @@ digraph destroy {
}
-->
Order of operations:
1. `C` is destroyed
1. `B` is destroyed
1. `A` is Destroyed
## Resource Replacement
Resource replacement is the logical combination of the above scenarios. Here we
will show the replacement steps involved when `B` depends on `A`.
In this first example, we simultaneously replace both `A` and `B`. Here `B` is
destroyed before `A`, then `A` is recreated before `B`.
@ -106,6 +119,12 @@ digraph replacement {
}
-->
Order of operations:
1. `B` is destroyed
1. `A` is destroyed
1. `A` is created
1. `B` is created
This second example replaces only `A`, while updating `B`. Resource `B` is only
updated once `A` has been destroyed and recreated.
@ -129,6 +148,12 @@ digraph replacement {
}
-->
Order of operations:
1. `A` is destroyed
1. `A` is created
1. `B` is updated
While the dependency edge from `B update` to `A destroy` isn't necessary in
these examples, it is shown here as an implementation detail which will be
mentioned later on.
@ -166,6 +191,12 @@ digraph replacement {
}
-->
Order of operations:
1. `B` is destroyed AND `A` is created
1. `B` is created
1. `A` is destroyed
Note that in this first example, the creation of `B` is inserted in between the
creation of `A` and the destruction of `A`. This becomes more important in the
update example below.
@ -190,6 +221,11 @@ digraph replacement {
}
-->
Order of operations:
1. `A` is created
1. `B` is updated
1. `A` is destroyed
Here we can see clearly how `B` is updated after the creation of `A` and before
the destruction of the _deposed_ resource `A`. (The prior resource `A` is
sometimes referred to as "deposed" before it is destroyed, to disambiguate it
@ -221,6 +257,9 @@ digraph update {
}
-->
Order of operations:
1. `B` is updated
1. `A` is destroyed
### Forced Create Before Destroy
@ -283,6 +322,12 @@ digraph replacement {
}
-->
Order of operations:
1. `A` is created
1. `B` is created
1. `B` is destroyed
1. `A` is destroyed
This also demonstrates why `create_before_destroy` cannot be overridden when
it is inherited; changing the behaviour here isn't possible without removing
the initial reason for `create_before_destroy`; otherwise cycles are always