moin
moin copied to clipboard
moinwiki
fix PARENTID usage, use MTIME less
Original report by Thomas Waldmann (Bitbucket: thomaswaldmann, GitHub: thomaswaldmann).
some views use MTIME based sorting of revisions, but they should rather use the order of revisions that is defined by the revisions' PARENTID pointer.
also import19 (1.9 -> 2.0 importer) doesn't create PARENTID metadata at all.
afaik the PARENTID chain is now correct except when an item's revision is destroyed thereby breaking the chain.
The original report suggests MTIME sorting may be incorrect or inferior to a PARENTID sorting. Is there an example when this may be true. Sorting by the PARENTID chain seems cumbersome.
for normal, linear history, mtime sorting should be fine (assuming monotonic time).
if there would be forks in history (which we do not generate, iirc), it would make a difference.
if one just has a list of revision, mtime sort is easier than by-parent-pointers.
otoh, if you have a specific revision and want to know it's parent, obviously using the parentid "pointer" is easier than trying to find out via timestamps.
As stated above, PARENTID is correct, except in the case when an item revision is destroyed. There is no failing transaction needing this functionality.
In addition to MTIME, there is REV_NUMBER in metadata.
Have not tried, but I think a search for rev_number > n, sorted, limit 1, would be an acceptable search alternative should there be a need to find a parent or closest ancestor revision.
A transaction needing a parent revision my want to know the parent was destroyed; a broken PARENTID link after a revision is destroyed may be the correct state.
Note parentid is ambiguous, in some places (hierarchic ACL processing) there is code using parentid to refer to a subitem's parent.
Lowered priority and removed milestone. Keeping this open as there is some code in /apps/feed/views.py that uses PARENTID.
