User:Dantman/Abstract Revision System
Extensions get to define new object types that get stored in the database with a whole revision history for each object.
- A class is registered with MediaWiki along with all the information needed for MediaWiki to handle it
- The extension gets access to a nice high-level API that takes control of things like revision creation, deletion, etc... and provides methods to go through the history, etc...
- Extensions can store whatever data they want not just text. (In fact we may serialize all data instead of providing a [gs]etText interface)
- A high-level diff system could be created. One that defines types and diff engine mappings. This would allow for easy diffs of WikiText as well as registration of diff engines that can handle diffs for different sets of data that extensions create.
- An option to integrate an object type with an extended protection system would be provided.
- Perhaps the recentchanges table could be extended slightly. Extensions could be allowed to optionally have items added to the rc page on object edit. And with a few definitions could allow filtering options to hide them, show them, or filter them added to Special:RecentChanges.
Storage
[edit]{...}rev{ision}
[edit]- {...}_id int unsigned, NOT NULL, auto_increment
- {...}_type varbinary(32), NOT NULL
- This defines the type which is used to separate revisions used by different extensions for different purposes.
- {...}_{obj?}, int unsigned, NOT NULL
- The id here is not tied to any predefined table. The extension gets to define the table which this maps to for any type it creates.
- {...}_text_id, int unsigned, NOT NULL
- Text is stored in the text storage as normal. However we may make all text serialized php data for these and we may use something like getData instead of getText since anything can come back.
- {...}_comment, tinyblob, NOT NULL
- How likely is it that a comment will be used?
- {...}_user, int unsigned, NOT NULL, DEFAULT 0
- {...}_user_text, varbinary(255), NOT NULL
- {...}_timestamp, binary(14), NOT NULL
- {...}_deleted, tinyint unsigned, NOT NULL, DEFAULT 0
{...}_len, int unsigned- {...}_parent_id, int unsigned
{...}_sha1, varbinary(32), NOT NULL
{...}{rev_}props
[edit]- {...}_id int unsigned, NOT NULL, auto_increment
- {...}_rev, int unsigned, NOT NULL
- {...}_prop, varbinary(32), NOT NULL
- {...}_value, varchar(255)
- ((Should [rev,prop] be unique or not?))
- ((Should we have a separate table for numeric props, such as abstract id mappings?))