https://bugzilla.wikimedia.org/show_bug.cgi?id=28488
Bug #: 28488
Summary: Implement revisionized properties table
Product: MediaWiki
Version: wikimedia-deployment
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: General/Unknown
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
Right now there is no way to attach information to an article without lozing it
over time (like "page_props" table does)
By having a revisionized / versioned properties table (like page_props) many
(if not, all) of the following will be possible:
1) Store page protection settings with the revision, undoing/rollbacking will
bring back protection info. As will deletion/undeletion
2) Move categories out of of wikitext. It has been proposed to do this before
(ie. store only in categorylinks and report changes in a null-revision edit
summary, like with protection currently) - however that is prone to abuse since
undoing a revision would mean having to manually copy/paste categories from the
history page edit summaries.
3) Maybe move langlinks out of wikitext ?
4) File properties [2]
5) Custom data for exentions (the prop_type column can be used by extension to
store other information, that would otherwise have to be stored in a new-table.
Some extensions appear to be doing this currently which could cause many tables
for the same purpose on a single wiki).
Using a versioned properties table will solve these problems. The revision is
connected to a set of properties, and undoing the revision will re-use the
previous set of properties (just like a rollback re-uses the same
mw_text.oldid_id / mw_revision.rev_id)
It also saves storage in the database as the set is only re-saved when
something has actually changed.
In other words, if the user only made a change in the article text, the same
old propid is used. If only props are modifed, the same textid/oldid stays in
use.
The properties table would have it's sets identified by a unique id, stored in
a column in the mw_revision table [1]. The properties table would either be
it's own incrementing integer or use the revision id. Comparison:
* properties-id
** Since multiple rows belong together the id spans multiple rows. An incrental
ID that spans multiple rows is not supported in MySQL and the only solution I
can think of is either keeping track of the id elsewhere, or getting the last
row and using the next number. Both are not clean.
* revision-id
** Using the revision-id is a lot easier. The revision data is saved, the
revision-id is known and used to store the properties. This also makes it easy
to track which revision last modified the properties (since the id matches the
revision-id that created the set of properties).
I think using the revision-id is probably the better choise. Only down side
could be that it may cause confusion since it would look like the revision-id,
not sure if that's an issue.
Highlights:
* Store data in properties table, versioned and each set has it's own id. If
only props change, same text.oldid is used, if only text changes same propid is
used.
* Connected revision to a set of properties, like text id (ie. a rollback
re-uses the oldid that revision, same would be for properties. Rolling back an
edit creates a null-revision with the same old text id and properties id.
--
Krinkle
[1] Adding a column to mw_revision is expensive to say the least but I'm not
sure there's a clean and long-term effient way around it.
[2] bug 25624 and http://www.mediawiki.org/wiki/License_integration
See also:
* (bug 167) Use a dedicated interface for adding interwiki/category links, not
wikitext
* (bug 25624) Making license and author information api accessible
* (bug 835) Syntax to transclude a page without categories and langlinks
* (bug 22293) Show previous protection level in protection log
* more...
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
