Related to https://bugzilla.wikimedia.org/show_bug.cgi?id=4150
I took a look at this bug today, and it seems that only the recentpages table stores the newness of a page. To show this information, a scheme change is apparently needed.
* I first thought at a rev_type field, similar to rc_type. This field would identify revisions creating a new page, but could also be used to flag special operations, such as page moves, or page protections that are currently null revisions.
* Bryan then suggested that a page_first, a foreign key to the first revision of the page, similarly to page_latest, could solve bug #4150.
On a sidenote, I also found #11181, "Mark bot edits in history", which might be related : if these features were to be implemented in the same time, a bitfield rev_flags could be worth looking at.
On Sun, Apr 6, 2008 at 10:28 PM, Nicolas Dumazet nicdumz@gmail.com wrote:
Related to https://bugzilla.wikimedia.org/show_bug.cgi?id=4150
I took a look at this bug today, and it seems that only the recentpages table stores the newness of a page. To show this information, a scheme change is apparently needed.
...
On a sidenote, I also found #11181, "Mark bot edits in history", which might be related : if these features were to be implemented in the same time, a bitfield rev_flags could be worth looking at.
I recall a conversation not too long ago about the added/removed characters feature on places like recentchanges or watchlists, and whether that could be implemented for histories or contributions pages: the problem again was that we have rev_len but no rev_old_len (whereas recentchanges has rc_old_len and rc_new_len).
Obviously there are performance reasons for having two separate tables, but would it be worth making most of the fields currently unique to recentchanges available to the revision table too?
wikitech-l@lists.wikimedia.org