Although roughly the queries look fine, it'd probably be worth adding some caching to it...
Version: 1.20.x
Severity: enhancement
Description
Description
Details
Details
- Reference
- bz39490
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T40450 Reimplement MediaWiki's info action (tracking) | ||
| Resolved | None | T43582 Show "Page information" toolbox link to info action also in history etc. | |||
| Invalid | None | T44238 Provide a link to the permalink for this page in the user interface (to page, not revision) | |||
| Resolved | None | T23572 Provide a safe and short permanent link to a page (e.g. by title, or stable page id) | |||
| Resolved | None | T18362 Add link to MediaWiki info action in UI | |||
| Resolved | None | T40451 Kill $wgAllowPageInfo; enable MediaWiki's info action by default | |||
| Resolved | Parent5446 | T41490 Add caching to info action |
Event Timeline
Comment Actions
So I'm not sure how to go about the whole unwatched pages caching issue. Maybe just cache the database queries rather than the actual rendered list? If anybody has any suggestions that'd be great.
Comment Actions
I agree, but the problem is that by the time the data is retrieved from the database and is processed, it's in a numerically indexed array. So what I'm saying is that there are two options: 1) Go through linearly and remove the information when we find it; or 2) instead of caching the actual processed array (which includes messages and whatnot), only cache the database queries. The problem with both solutions is that they're cause inefficiency.
Comment Actions
madman.enwiki wrote:
The latter is what I'd do, caching the results of pageCounts rather than pageInfo, containing the (very relatively) expensive queries Reedy was talking about in opening this bug.
Comment Actions
Mhm, that's what I am thinking as well. I should be able to make a patch for this relatively easily.
Comment Actions
The info action will ultimately include information such as number of transclusions or number of file uses. My concern is that updates (such as a new transclusion) won't propagate to these cached counts and users will end up seeing bad data.
Comment Actions
(In reply to comment #7)
The info action will ultimately include information such as number of
transclusions or number of file uses. My concern is that updates (such as a new
transclusion) won't propagate to these cached counts and users will end up
seeing bad data.
Which is the same as most cached data in MediaWiki...
Comment Actions
True, but in that case, in the patch that introduces that information to the page, just put something that invalidates the InfoAction cache for every time a new templatelink is added.