That would be nice. I haven't kept up with the last couple of versions, but there used to also be a problem with subcategories not showing up if they didn't sort into the initial 200 in the query limit. If this is going to get fixed, it would be nice if there was a fix for that too, if it's not already addressed...we're still on 1.9x
My badly named SplitCategoryPage extension was written to do that, but is only suitable for operations that are much, much smaller than wikimedia projects. Nevertheless, if you want to see it in action
http://gowiki.tamu.edu/wiki/index.php/Category:Eukaryota
This is a category with 111867 articles. The wiki is running on a single Intel quad Mac XServe blade that it shares with another wiki. No squid, no memcache. Traffic is microscopically (or perhaps femtoscopically?) small by WMF standards.
Jim
On Feb 20, 2008, at 10:52 PM, Andrew Garrett wrote:
On 2/21/08, Simetrical Simetrical+wikilist@gmail.com wrote:
On Wed, Feb 20, 2008 at 8:59 PM, Steve Bennett stevagewp@gmail.com wrote:
Why is that? Couldn't we store the count somewhere and inc/dec it as required?
Of course. We just need to make a category table. Would cut down on the size of categorylinks, too, if we could use category id's.
Actually, I've been looking into this recently (It's a very frequent personal request). I very much like Simetrical's idea of having a separate category table (I felt bad introducing a schema change to store a silly little count in the database per category). Domas tells me that checking the number of items in a category is about a five-second query for very big categories - so we probably don't want to rebuild it at all - even when saving a page with a category in it (think about it, 5-6 big categories would tie up the database servers for a minute or more).
So, if I were to implement this tomorrow, this is what I would do (feedback welcomed):
- Create a 'category' table starting off with a c_id, c_page_id, and
c_count. This would fit in very nicely with something Tim was talking about last night - allowing flags to be put on categories (i.e. "don't show this category on the article", "show icon Image:X in the top corner of articles in this category", et cetera) which could be put in a separate column of the category table.
- On save of a category, or a page including that category, insert the
requisite category entry (this would save a dirty great big migration script).
- When a categorylinks item is INSERTED or DELETED on links-update
(the code is nice in that it only inserts/deletes those items which have been added/removed), do the requisite incrementing/decrementing on the category table.
- Display the count on the category page.
This would add a performance penalty of a potentially very expensive database query per category, as a once-off, on page-save. It would enable a whole bunch of new functionality, such as proper display of membership counts on category pages, the stuff Tim was talking about last night with assigning a bit of metadata to categories (to make them a bit more useful).
I'm willing to look into implementing this in the next few months, depending upon how my understanding of the technical details corresponds to reality.
-- Andrew Garrett
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054