2009/6/5 sl contrib <[email protected]>: > I guess it would be the same if one sorted on revision id (rather than > page_latest)? > Is there a proposal one could forward to make this more efficient, by > somehow also indexing on revision id? >> >> > that people can have a look? >> This'll probably work (albeit breaking a few things such as apfrom, as >> you mentioned), but due to the inefficient queries involved, it won't >> make it into the MediaWiki core. > > Again, is there something that could be done to make it more efficient? > Or perhaps one could put some less efficient code in, but with a switch to > disable it on large wikis? > Just to give a little background, why I think this is important: Mediawiki > is an important platform for Open Educational Resources, and when > considering scenarios in developing countries, bandwidth is expensive, and > so mirroring is important. Of course once you mirror, you want to start up > to date, so being able to get updates since a revision or a date is > important. > Would really like to hear your ideas on what the best way forward is! IMO the best way forward is still to use list=recentchanges whenever possible. A list=allrevisions module, which just grabs all revisions from the revision table (paging by rev_id), could easily be written to accommodate for getting revisions older than $wgRCMaxAge , and for initial imports without history, generator=allpages&prop=revisions (gets the top revision of every page) should do.
Roan Kattouw (Catrope) _______________________________________________ Mediawiki-api mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
