Now that the earlier DB outage is taken care of, I'm running the DB schema changelets which have held back main code updates on the live site since the week before Wikimania.
Updates to image, oldimage, and archive tables are being applied on the slave servers. The new additions will:
* Speed up user renames * Allow cleaner lookups of uploaded files by name * Store of file content hashes for various purposes * Store page_id of deleted pages for later use in restore or other sorting out of fun situations
There will be intermittent slave lag while these run.
Once all the slaves are done, we'll have to swap masters and run them on the old masters before updating code.
-- brion vibber (brion @ wikimedia.org)
Great.
Some notes about ar_page_id:
I am finishing up code that will stop article histories from being merged (merges, if done at all, should be using the proper software mechanisms, not hacks). Though I'll commit it with the other rev_deleted stuff (which awaits log_id).
On my installation, one can no longer move [[Wikipedia]] over [[George Bush]] (deleted to make way for move) then delete/restore the revisions, which would mix 60,000+ interwove revisions (which is fun to fix...).
Also, such is needed for using a restore-point based undeletion method (which works well with paging for special:undelete), since you can't check all revs from one page and restore those only anymore. Paging has the advantage of not having your browser crash over 35,000 revisions.
-Aaron Schulz
From: Brion Vibber brion@wikimedia.org Reply-To: Wikimedia developers wikitech-l@lists.wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] Schema changes in progress Date: Sat, 11 Aug 2007 14:49:30 -0400
Now that the earlier DB outage is taken care of, I'm running the DB schema changelets which have held back main code updates on the live site since the week before Wikimania.
Updates to image, oldimage, and archive tables are being applied on the slave servers. The new additions will:
- Speed up user renames
- Allow cleaner lookups of uploaded files by name
- Store of file content hashes for various purposes
- Store page_id of deleted pages for later use in restore or other
sorting out of fun situations
There will be intermittent slave lag while these run.
Once all the slaves are done, we'll have to swap masters and run them on the old masters before updating code.
-- brion vibber (brion @ wikimedia.org)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
_________________________________________________________________ Tease your brain--play Clink! Win cool prizes! http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2
On 8/11/07, Aaron Schulz jschulz_4587@msn.com wrote:
I am finishing up code that will stop article histories from being merged (merges, if done at all, should be using the proper software mechanisms, not hacks).
Are there any proper software mechanisms available, though?
Not that I know of. I'll write some extension if no one else does.
Certainly it could be much faster by just setting rev_page_id values, rather moving pages and deleting crap all over the place. I could make it timeframe based as well (say from first rev -> some time) to preserve continuity and such. Some basic checking for time overlap could be done to.
Simetrical-3 wrote:
Are there any proper software mechanisms available, though?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/12/07, Voice of All jschulz_4587@msn.com wrote:
Not that I know of. I'll write some extension if no one else does.
Please do so *before* breaking existing functionality. And personally, I would view such basic history management as more suited to core than extensions (same goes for the Duplicator extension). It's critical for any sort of robust version control.
I haven't committed anything yet, so the sky hasn't fallen just yet. I won't be doing so for a good while at least, while I test more and wait for log_id anyway. I suppose I could write it in the core, doesn't really matter to me.
Simetrical-3 wrote:
On 8/12/07, Voice of All jschulz_4587@msn.com wrote:
Not that I know of. I'll write some extension if no one else does.
Please do so *before* breaking existing functionality. And personally, I would view such basic history management as more suited to core than extensions (same goes for the Duplicator extension). It's critical for any sort of robust version control.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Simetrical wrote:
On 8/12/07, Voice of All jschulz_4587@msn.com wrote:
Not that I know of. I'll write some extension if no one else does.
Please do so *before* breaking existing functionality. And personally, I would view such basic history management as more suited to core than extensions (same goes for the Duplicator extension). It's critical for any sort of robust version control.
Amen.
- -- brion
On 8/12/07, Aaron Schulz jschulz_4587@msn.com wrote:
Great.
Some notes about ar_page_id:
I am finishing up code that will stop article histories from being merged (merges, if done at all, should be using the proper software mechanisms, not hacks). Though I'll commit it with the other rev_deleted stuff (which awaits log_id).
On my installation, one can no longer move [[Wikipedia]] over [[George Bush]] (deleted to make way for move) then delete/restore the revisions, which would mix 60,000+ interwove revisions (which is fun to fix...).
In the process of disabling this feature, are you going to provide a new way to merge article histories?
Sebastian
On 12/08/07, Sebastian Moleski sebmol@gmail.com wrote:
In the process of disabling this feature, are you going to provide a new way to merge article histories?
That's exactly what Simetrical was getting at.
Rob Church
I'll add a new special page to the core. I'm already pretty much done with it, just testing around and tweaking.
Rob Church wrote:
On 12/08/07, Sebastian Moleski sebmol@gmail.com wrote:
In the process of disabling this feature, are you going to provide a new way to merge article histories?
That's exactly what Simetrical was getting at.
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org