Change Details

Per {T181555}, we want to replace the existing ExternalStore entries that are using HistoryBlob objects with different "objects" that don't require the use of PHP's `unserialize()` method. On WMF sites, the ES clusters with these objects are on databases that are running read-only since we normally never have any need to change them. But that's a problem for this non-normal situation. I see two ways to handle this: # Make the old ES databases writable temporarily so the existing rows can be updated by the migration script. # Write all the replaced objects to a new ES cluster. ## Write them to one of the existing active clusters. ## Create a new cluster just for this migration. The tradeoff here is storage space versus whatever difficulty is involved in making these clusters temporarily writable. The code I've written for T181555 will work with either option.

Per {T181555}, we want to replace the existing ExternalStore entries that are using HistoryBlob objects with different "objects" that don't require the use of PHP's `unserialize()` method. On WMF sites, the ES clusters with these objects are on databases that are running read-only since we normally never have any need to change them. But that's a problem for this non-normal situation. I see ~~two~~ three ways to handle this: # Make the old ES databases writable temporarily so the existing rows can be updated by the migration script. # Write all the replaced objects to a new ES cluster. ## Write them to one of the existing active clusters. ## Create a new cluster just for this migration. # (added after discussion) Run recompressTracked.php over the existing ES clusters, including the ones that are already compressed. The tradeoff here is storage space versus whatever difficulty is involved in making these clusters temporarily writable. The code I've written for T181555 will work with either option (well, not yet option 3, but that'd be easy to account for).

Per {T181555}, we want to replace the existing ExternalStore entries that are using HistoryBlob objects with different "objects" that don't require the use of PHP's `unserialize()` method. On WMF sites, the ES clusters with these objects are on databases that are running read-only since we normally never have any need to change them. But that's a problem for this non-normal situation. I see two~~two~~ three ways to handle this: # Make the old ES databases writable temporarily so the existing rows can be updated by the migration script. # Write all the replaced objects to a new ES cluster. ## Write them to one of the existing active clusters. ## Create a new cluster just for this migration. # (added after discussion) Run recompressTracked.php over the existing ES clusters, including the ones that are already compressed. The tradeoff here is storage space versus whatever difficulty is involved in making these clusters temporarily writable. The code I've written for T181555 will work with either option (well, not yet option 3, but that'd be easy to account for).