Change Details

There are two places in revision storage where PHP serialization is currently used: * `Revision::decompressRevisionText()`'s `object` flag, used for generic compression and as a hack to avoid migrating data from the MediaWiki 1.4 schema to the schema introduced in 1.5. * `ExternalStoreDB` can store objects that hold more than one revision, as a compression mechanism. Removing the use of PHP serialization in these places will involve finding the relevant rows and re-saving them in a format that doesn't require PHP serialization, which in turn will require identifying the different kinds of objects that can be present and figuring out how to replace them. It seems the HistoryBlob interface is intended to be implemented by the objects used in both of these places. Implementing classes include: * ConcatenatedGzipHistoryBlob: Effectively an associative array mapping an md5 hash to content, which is then serialized and gzipped. * DiffHistoryBlob: A base version and an array of successive diffs to generate subsequent versions. Which is then serialized and gzipped. * HistoryBlobStub: A wrapper for ConcatenatedGzipHistoryBlob. * HistoryBlobCurStub: Accesses the MW 1.4 cur table. Replacement will involve either loading the data and re-saving it without fancy compression, or figuring out a method to save and restore the compression without using PHP's serialization.

There are two places in revision storage where PHP serialization is currently used: * `Revision::decompressRevisionText()`'s `object` flag, used for generic compression and as a hack to avoid migrating data from the MediaWiki 1.4 schema to the schema introduced in 1.5. * `ExternalStoreDB` can store objects that hold more than one revision, as a compression mechanism. Removing the use of PHP serialization in these places will involve finding the relevant rows and re-saving them in a format that doesn't require PHP serialization, which in turn will require identifying the different kinds of objects that can be present and figuring out how to replace them. It seems the HistoryBlob interface is intended to be implemented by the objects used in both of these places. Implementing classes include: * ConcatenatedGzipHistoryBlob: Effectively an associative array mapping an md5 hash to content, which is then serialized and gzipped. * DiffHistoryBlob: A base version and an array of successive diffs to generate subsequent versions. Which is then serialized and gzipped. * HistoryBlobStub: A wrapper for one of the above. * HistoryBlobCurStub: Accesses the MW 1.4 cur table. Replacement will involve either loading the data and re-saving it without fancy compression, or figuring out a method to save and restore the compression without using PHP's serialization.

There are two places in revision storage where PHP serialization is currently used: * `Revision::decompressRevisionText()`'s `object` flag, used for generic compression and as a hack to avoid migrating data from the MediaWiki 1.4 schema to the schema introduced in 1.5. * `ExternalStoreDB` can store objects that hold more than one revision, as a compression mechanism. Removing the use of PHP serialization in these places will involve finding the relevant rows and re-saving them in a format that doesn't require PHP serialization, which in turn will require identifying the different kinds of objects that can be present and figuring out how to replace them. It seems the HistoryBlob interface is intended to be implemented by the objects used in both of these places. Implementing classes include: * ConcatenatedGzipHistoryBlob: Effectively an associative array mapping an md5 hash to content, which is then serialized and gzipped. * DiffHistoryBlob: A base version and an array of successive diffs to generate subsequent versions. Which is then serialized and gzipped. * HistoryBlobStub: A wrapper for ConcatenatedGzipHistoryBlobone of the above. * HistoryBlobCurStub: Accesses the MW 1.4 cur table. Replacement will involve either loading the data and re-saving it without fancy compression, or figuring out a method to save and restore the compression without using PHP's serialization.