This document shows a set of write operations that provide concrete examples of how the Resource Processing Algorithm is applied based on the state of the Registry and the incoming request. They are meant to be read in order to avoid repeating the same commentary for each example.
Each example:
{
"groups": {
"dirs": {
"singular": "dir",
"resources": {
"files": {
"singular": "file",
"hasdocument": false,
"versionmode": "createdat"
}
}
}
}
}
|
Initial State: Request: |
Final State: |
Notes:
f1 is created.versionid of 1 is created per the default versionid
naming algorithm defined in the specification. ancestor value is 1 (points to itself) because it is the
root of a hierarchy tree.PATCH instead of PUT will yield the exact same results.|
Initial State: Request: |
Final State: |
Notes:
files collection.name, so that will appear both at
the Resource level and within the Version in the versions collection.|
Initial State: Request: |
Final State: |
Notes:
f1, Versions v1 and v2 are created.name will be ignored because when versionid and
meta.defaultversionid are absent, but versions is not empty, all
Resource.* attributes are ignored.createdat timestamp they are sorted
alphabetically by their versionid values in order to set their ancestor
attributes.v2 becomes the newest and therefore the default Version.1 <- v1 <- v2.PATCH would yield the exact same results.|
Initial State: Request: |
Final State: |
Notes:
1 is created because we used meta.defaultversionid as a clue
that Resource.* attributes are for v1.name) is ignored because v1 is part of the
request's versions collection.v1(2020) <- v3 (now) <- v2 (3030).v2 is default because it has the newest createdat timestamp.|
Initial State: Request: |
Final State: |
Notes:
1 is created because we used meta.defaultversionid as a clue
that Resource.* attributes are for v1.name) are assigned to v1.v1(now) <- v2 (now) <- v3 (now).v3 is default because it is the highest alphabetically.|
Initial State: Request: |
Final State: |
Notes:
v1 is created due to meta.defaultversionid being set.v1 isn't part of the request's versions collection, the Resource.*
attributes will be applied.|
Initial State: Request: |
Final State: |
Notes:
v0 is created because it is not present in versions.v1 (2020) <- v0 (now) <- v2 (now).|
Initial State: Request: |
Final State: |
Notes:
v0 (the current default Version) is updated with the
Resource.* attributes. Notice that versionid is not present in the request
and that it isn't needed as a "clue" because the Resource already exists
so we know what the current default Version is.meta.defaultversionid is not used as a clue as to the "current"
default versionid, it will be used to calculate the resulting default
Version due to defaultversionsticky being true.v1 (2020) <- v0 (2021) <- v2 (now).|
Initial State: Request: |
Final State: |
Notes:
versionid at the Resource level is needed to ensure that
the current default Version is v0 and that it is created.versionid and meta.defaultversionid)
have different values because we need to create v0 as the current default
Version when processing the Resource.* attributes, but then assign v1 as
the resulting default Version. This means that in the previous example
versionid was not needed, but in this example it is to yield the correct
(same) net result.v1 (2020) <- v0 (now) <- v2 (now).|
Initial State: Request: |
Final State: |
Notes:
v0 is created due to the presence of versionid. Which means
meta.defaultversionid is ignored for the purpose of determining the
current default Version. However, it is also ignored when calculating the
resulting default Version due to defaultversionsticky being false.v1 (2020) <- v0 (now) <- v2 (now).|
Initial State: Request: |
Final State: |
Notes:
versionid is not present, meta.defaultversionid will
be used as the "clue" for the current default Version.|
Initial State: Request: |
Final State: |
Notes:
v1, and v1 is not in the request's versions
collection, so it's "name" attribute is updated.v2 is updated.meta.defaultversionid references a non-existing Version, no error is
generated because its value is ignored due to meta.defaultversionsticky
being false.v2 (2020) <- v1 (2025).|
Initial State: Request: |
Final State: |
Notes:
v2 (the current default
Version) appears in the request's versions collection.v2, setting defaultversionsticky to true
only takes effect after the default Version is recalculated. This is due to
the fact that PUT is a complete replacement and meta.defaultversionid
not being in the request is akin to setting it to null in the request. In
the next example we'll see how PATCH changes this semantics.v2 (2020) <- v1 (2025).|
Initial State: Request: |
Final State: |
Notes:
v2 (the current default Version) being in
the request's versions collection.PATCH, unlike the previous example where
meta.defaultversionid was implicitly set to null, in this case its value
remains unchanged. So, when meta.defaultversionsticky is set to true the
current default Version becomes "sticky".v2 (2020) <- v1 (2025).|
Initial State: Request: |
Final State: |
Notes:
name is deleted because PUT is a complete replacement
of all attributes.meta are updated.|
Initial State: Request: |
Final State: |
Notes:
name is unchanged due to the use of PATCH instead of
PUT.PATCH does update the epoch and modifiedat timestamps of the
current default Version.meta sub-object is unchanged.|
Initial State: Request: |
Final State: |
Notes:
name attribute is deleted.description is updated.epoch and modifiedat are automatically updated.meta sub-object is unchanged.|
Initial State: Request: |
Final State: |
Notes:
name attribute is unchanged.description is updated.epoch and modifiedat are automatically updated.meta sub-object is unchanged.|
Initial State: Request: |
Final State: |
Notes:
name attribute is deleted due to the operation
being a PUT. Its epoch and modifiedat are automatically updated.meta.defaultversionsticky is set to true, and since there is only one
Version the calculated default Version remains 1.|
Initial State: Request: |
Final State: |
Notes:
name is unchanged, but epoch and modifiedat are automatically updated.1 becomes sticky.name attribute is unchanged, but epoch and
modifiedat are automatically updated.meta.defaultversionsticky is set to true, and since there is only one
Version the calculated default Version remains 1.|
Initial State: Request: |
Final State: |
Notes:
meta sub-object, no attributes
on Version v1 or v2 are modified.v1 and it is
sticky.meta's epoch and modifiedat values are updated.v1 (2025) <- v2 (2025).|
Initial State: Request: |
Final State: |
Notes:
meta.defaultversionsticky to true
explicitly, setting meta.defaultversionid via a PATCH implicitly
sets meta.defaultversionsticky to true. If this operation used PUT
instead, the error would not have been generated and meta.defaultversionid
would have been ignored.|
Initial State: Request: |
Final State: |
Notes:
PUT. If
meta.defaultversionsticky had not been included in the request with a
value of true then defaultversionid would have been ignored.|
Initial State: Request: |
Final State: |
Notes:
v2 is created with a createdat value of 1998.v1 is updated (name, createdat, epoch and modifiedat).v2 was just created, v1 is still the default Version because it has
a newer createdat value. And it is now sticky per the request.v2 (1998) <- v1 (1999).|
Initial State: Request: |
Final State: |
Notes:
v1 is in request's versions collection.v2 is default because it's the highest alphabetically.|
Initial State: Request: |
Final State: |
Notes:
v1 is in the request's versions collection.v2 is default because it's the highest alphabetically,meta.defaultversionid being specified, it is ignored when
calculating the default Version because meta.defaultversionsticky is not
true.|
Initial State: Request: |
Final State: |
Notes:
|
Initial State: Request: |
Final State: |
Notes:
?setdefaultversionid flag has the same semantics as setting
meta.defaultversionid=v1 and meta.defaultversionsticky=true.|
Initial State: Request: |
Final State: |
Notes: