1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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 deleted, 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 current
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.
|
