Change Details

Instead of storing GeoJSON for `<mapframe>` tags in the `page_props` table, we should store it in a table that's really just a key-value store, where the keys are the hashes and the values are the GeoJSON blobs. This is basically solution #1 from {T119043} but without the second rev tracking table. We would need to modify the code that writes the GeoJSON blobs to `page_props` (indirectly through ParserOutput methods) to instead write to this new table, and modify the api.php module to read from this new table instead of `page_props`. We'd also need a migration script (or have the API module read from both).

Instead of storing GeoJSON for `<mapframe>` tags in the ~~page_props table~~ parser cache, we should store it in a table that's really just a key-value store, where the keys are the hashes and the values are the GeoJSON blobs. This is basically solution #1 from {T119043} but without the second rev tracking table. We would need to modify the code that writes the GeoJSON blobs ~~to page_props (indirectly through ParserOutput methods)~~ to instead write to this new table, and modify the api.php module to read from this new table ~~instead of page_props~~. We'd also need a migration script (or have the API module read from both).

Instead of storing GeoJSON for `<mapframe>` tags in the `~~page_props` tablee~~ parser cache, we should store it in a table that's really just a key-value store, where the keys are the hashes and the values are the GeoJSON blobs. This is basically solution #1 from {T119043} but without the second rev tracking table. We would need to modify the code that writes the GeoJSON blobs to `~~to page_props` (indirectly through ParserOutput methods)~~ to instead write to this new table, and modify the api.php module to read from this new table ~~instead of `page_props`~~. We'd also need a migration script (or have the API module read from both).