Last modified: 2010-05-15 15:37:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3612 - Function to compress or delete old content in database
Function to compress or delete old content in database
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.5.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Help:R...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-05 13:24 UTC by Sider
Modified: 2010-05-15 15:37 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sider 2005-10-05 13:24:59 UTC
Since MW 1.5beta3, compressOld.php doesn't seem to work. In database the "old
table" doesn't exist anymore. A tool, special page or whatever is needed to
reduce the size of database and delete obsolete content. Refer for future
descriptions here: http://meta.wikimedia.org/wiki/Help:Reduce_size_of_the_database .
Comment 1 Rob Church 2005-10-05 13:31:52 UTC
Just to clarify; by obsolete data, do *you* mean old page revisions?
Comment 2 Sider 2005-10-05 13:35:16 UTC
Right, perhaps older than three month. This could be a variable to set in
LocalSettings.php or AdminSettings.php. :)
Comment 3 Rob Church 2005-10-05 13:37:24 UTC
You misunderstood my changing of the bug options. This bug effectively affects
all users, regardless of OS or platform (because it doesn't exist for anyone);
also, it's not a bug fix, it's a feature request/enhancement. And it's not
*critical* (think in terms of what the Wikimedia Foundation wants, if you want a
more accurate way of thinking how the developers regard critical issues) so it's
got normal priority.
Comment 4 Sider 2005-10-05 13:41:14 UTC
I cant agree to you, because these old revisions *cause much costs of hardware*,
so it should be major, perhaps even critical.
Comment 5 Rob Church 2005-10-05 15:59:10 UTC
I'm sorry, but I can't continue to argue over this. I'll have our CTO or one of
the other devs take a gander and relabel as required.
Comment 6 Rob Church 2005-10-05 16:00:43 UTC
One point worth making is that the WMF tends to need to keep all old revisions,
for various reasons, including GFDL issues.
Comment 7 Sider 2005-10-05 18:46:18 UTC
I think, that this point should be discussed by community, not only by you and me.

If its not possible to delete them, perhaps compressing would be ok. This is no 
new feature, because it was already there before and compressOld.php is still in 
the install package, but broken.

You can't think that *causing costs is a good solution* here, do you?
Comment 8 Brion Vibber 2005-10-05 19:17:15 UTC
compressOld.php works fine as far as I know in current 1.5. (Check rc4 and CVS.)
Comment 9 Sider 2005-10-06 07:39:04 UTC
can I use compressOld.php of 1.5rc4 in 1.5beta3?
Comment 10 Brion Vibber 2005-10-06 22:52:18 UTC
Upgrade to 1.5.0.
Comment 11 Sider 2005-10-07 09:58:35 UTC
How to do it without causing problems? I searched and only found this:

http://meta.wikimedia.org/wiki/Help:Upgrading_MediaWiki

The upgrade procedure for 1.5 is not yet available there.
Comment 12 Rob Church 2005-10-07 18:29:05 UTC
You should be able to copy the files for 1.5 over the top of those for 1.5rc4,
but I'd recommend backing up the wiki folder (files) and the mySQL database
before doing this, as a precaution.
Comment 13 Sider 2005-10-07 20:01:50 UTC
I run 1.5beta3 now, is it possible in the same way? Any database changes needed 
or upgrade script?
Comment 14 Brion Vibber 2005-10-07 21:09:43 UTC
If you look in the source archive, you'll see these files:
RELEASE-NOTES
UPGRADE
INSTALL

They are in capital letters for a reason. Please read them.
Comment 15 Sider 2005-10-09 11:43:48 UTC
I just did as you said. The update to 1.5rc4 works fine with the default install 
script there, but when i execute compressold.php it says the following: 
compressOld is known to be broken at the moment. So i checked CVS and got 
1.6alpha working with this failure at the end: 

PHP 5.0.4 installed 
Warning: PHP's register_globals option is enabled. Disable it if you can. 
MediaWiki will work, but your server is more exposed to PHP-based security 
vulnerabilities. 
PHP server API is apache2handler; ok, using pretty URLs (index.php/Page_Title) 
Have XML / Latin1-UTF-8 conversion support. 
PHP is configured with no memory_limit. 
Have zlib support; enabling output compression. 
Neither Turck MMCache nor eAccelerator are installed, can't use object caching 
functions 
GNU diff3 not found.
Found GD graphics library built-in, image thumbnailing will be enabled if you 
enable uploads. 
Installation directory: D:\apachefriends\xampp\htdocs\wiss 
Script URI path: /wiss 
Environment checked. You can install MediaWiki. 
Warning: $wgSecretKey key is insecure, generated with mt_rand(). Consider 
changing it manually. 
Database type: mysql 
Trying to connect to database server on localhost as root... 
Connected as root (automatic)
Connected to 4.1.12 
Database wikidb exists 
There are already MediaWiki tables in this database. Checking if updates are 
needed... 
DB user account ok 
...hitcounter table already exists.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...logging table already exists.
...validate table already exists.
...user_newtalk table already exists.
...transcache table already exists.
...trackbacks table already exists.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...have rc_type field in recentchanges table.
...have rc_ip field in recentchanges table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...have user_real_name field in user table.
...have user_token field in user table.
...have user_email_token field in user table.
...have log_params field in logging table.
...have ar_rev_id field in archive table.
...have ar_text_id field in archive table.
...have page_len field in page table.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have img_media_type field in image table.
...have val_ip field in validate table.
...have ss_total_pages field in site_stats table.
...have iw_trans field in interwiki table.
...already have interwiki table
...indexes seem up to 20031107 standards
Already have pagelinks; skipping old links table updates.
...image primary key already set.
The watchlist table is already set up for email notification.
...user table does not contain old email authentication field.
Logging table has correct title encoding.
...page table already exists.
revision timestamp indexes already up to 2005-03-13
...rev_text_id already in place.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...already have pagelinks table.
No img_type field in image table; Good.
Already have unique user_name index.
...user_groups table already exists.
...user_groups is in current format.
...wl_notificationtimestamp is already nullable.
Updating indexes to 20050912: Query "ALTER TABLE wissimage
 ADD INDEX img_major_mime (img_major_mime)
" failed with error code "No database selected".

if I execute compressOld.php, i got the same again: compressOld is known to be 
broken at the moment. Whats wrong? :-)
Comment 16 Sider 2005-10-09 12:12:44 UTC
I startet the process again with 1.5beta3 and updated via CVS to 1.5.0. This 
worked fine and without failures, but if I execute compressOld.php, i got the 
same again: compressOld is known to be broken at the moment. -.-
Comment 17 Sider 2005-11-11 10:50:26 UTC
Any update here?
Comment 18 Rob Church 2005-11-11 11:11:02 UTC
Someone was asking about this in the IRC channel last night, and I've got it
pegged down to have a look, so I'll probably take a look at the compressOld.php
script while I'm at it.
Comment 19 Brion Vibber 2005-11-16 07:34:41 UTC
Looks like somebody forgot to remove the old compressOld.inc/.php on the REL1_5 branch 
when the new storage code was moved into maintenance/storage.

Run the version in maintenance/storage, not the one in maintenance/. I'll make sure the 
old one is removed in the next 1.5 release.
Comment 20 Sider 2005-12-01 14:17:58 UTC
Seems to work now.
Comment 21 Sider 2006-01-25 09:34:15 UTC
Any suggestion - perhaps a SQL query - for killing the old revisions?
Comment 22 Brion Vibber 2006-01-25 10:46:36 UTC
Problem was fixed, not sure why this was reopened.
Comment 23 Brion Vibber 2006-01-25 10:52:43 UTC
Could you open a new enhancement request for a delete-old-revisions script?
While it's evil and horrible, it gets asked for a lot ;) so maybe we could
include something.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links