summaryrefslogtreecommitdiffstats
path: root/notes/UNSORTED.txt
diff options
context:
space:
mode:
authorBryan Newbold <bnewbold@robocracy.org>2019-01-04 17:41:27 -0800
committerBryan Newbold <bnewbold@robocracy.org>2019-01-04 17:41:27 -0800
commit084e476957ce80b456dcf0575de4efc7331d34f9 (patch)
tree5377ef32c140ef6a0b73d67296eeacf17edcabc9 /notes/UNSORTED.txt
parentd7b0a156d2a3a21e2bf5afc3e4b97e7cf1044248 (diff)
downloadfatcat-084e476957ce80b456dcf0575de4efc7331d34f9.tar.gz
fatcat-084e476957ce80b456dcf0575de4efc7331d34f9.zip
clean up notes a tiny bit
Diffstat (limited to 'notes/UNSORTED.txt')
-rw-r--r--notes/UNSORTED.txt40
1 files changed, 40 insertions, 0 deletions
diff --git a/notes/UNSORTED.txt b/notes/UNSORTED.txt
new file mode 100644
index 00000000..3960f5eb
--- /dev/null
+++ b/notes/UNSORTED.txt
@@ -0,0 +1,40 @@
+
+Not allowed to PUT edits to the same entity in the same editgroup. If you want
+to update an edit, need to delete the old one first.
+
+The state depends only on the current entity state, not any redirect. This
+means that if the target of a redirect is delted, the redirecting entity is
+still "redirect", not "deleted".
+
+Redirects-to-redirects are not allowed; this is enforced when the editgroup is
+accepted, to prevent race conditions.
+
+Redirects to "work-in-progress" (WIP) rows are disallowed at update time (and
+not re-checked at accept time).
+
+"ident table" parameters are ignored for entity updates. This is so clients can
+simply re-use object instantiations.
+
+The "state" parameter of an entity body is used as a flag when deciding whether
+to do non-normal updates (eg, redirect or undelete, as opposed to inserting a
+new revision).
+
+In the API, if you, eg, expand=files on a redirected release, you will get
+files that point to the *target* release entity. If you use the /files endpoint
+(instead of expand), you will get the files pointing to the redirected entity
+(which probably need updating!). Also, if you expand=files on the target
+entity, you *won't* get the files pointing to the redirected release. A
+high-level merge process might make these changes at the same time? Or at least
+tag at edit review time. A sweeper task can look for and auto-correct such
+redirects after some delay period.
+
+=> it would not be too hard to update get_release_files to check for such
+ redirects; could be handled by request flag?
+
+`prev_rev` is naively set to the most-recent previous state. If the curent
+state was deleted or a redirect, it is set to null.
+
+This parameter is not checked/enforced at edit accept time (but could be, and
+maybe introduce `prev_redirect`, for race detection). Or, could have ident
+point to most-recent edit, and have edits point to prev, for firmer control.
+