Last modified: 2012-12-06 20:36:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36320, the corresponding Phabricator task for complete and up-to-date bug report information.
First Last Prev Next    This bug is not in your last search results.
Bug 34320 - remove obsolete database field rc_new
remove obsolete database field rc_new
Status: NEW
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.20.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: schema-change
Depends on:
Blocks: 16660
  Show dependency tree / graph
 
Reported: 2012-02-10 14:26 UTC by db [inactive,noenotif]
Modified: 2012-12-06 20:36 UTC (History)
2 users (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description db [inactive,noenotif] 2012-02-10 14:26:17 UTC 
The databasefield recentchanges.rc_new is marked as obsolete in RecentChanges.php

Please drop this field to clean up the table.

The problem is, that this field is used at many places in core. You can remove it with a check of the field "rc_type" against the const RC_NEW.

Thanks.
Comment 1 Umherirrender 2012-08-03 22:19:22 UTC 
changed some rc_new with Gerrit change #17622, but the field is part of an index, that makes it not easy to remove.
Comment 2 Alexandre Emsenhuber [IAlex] 2012-08-04 06:03:28 UTC 
Can we please keep such fields for a while, it makes very difficult to test older MediaWiki versions with the same database as the one for master.
Comment 3 db [inactive,noenotif] 2012-12-06 20:36:16 UTC 
(In reply to comment #2)
> Can we please keep such fields for a while, it makes very difficult to test
> older MediaWiki versions with the same database as the one for master.

Yes, that sounds good. Keeping the field at least one release after the last usage was removed. Than it is possible to rollback a upgrade without errors.

Maybe adding @deprecated in tables.sql as a comment near the field can make that clearer, because some fields left over in the past.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.

Navigation
Links