- Early 2019, investigate normalization of wb_terms
- T219175 - March 2019 Trail blaze #1 - Migrating data from wb_terms to a new schema.
- TBD - Read from new schema in production
- TBA tickets for reading for each usecase (for wikidata & wikibase), T198866 will be relevant here?
- TBD - Use Elastic search for some bulk term lookups?
- T194158: Find a solution for term lookup without wb_terms
- TBA elasticsearch investigation ticket & details / spec
- TBD - Drop the wb_terms table in production
Tickets that can be closed once the table is dead
- Any open tickets on this board: https://phabricator.wikimedia.org/tag/wikidata-ugly-cat-trailblaze_wb_terms_trail_blazing/
- T86530: Replace wb_terms table with more specialized mechanisms for terms (tracking) - Follows the same sort of idea as this ticket, but has lots of cruft surrounding it, so bets to leave it where it is rather than pull it into a subtask of this task.
- T197161: Gather information on users of wb_terms replicas on WMF cloud infrastructure - Part of old trail blaze investigation
- T205194: Make sure EntityLinkFormatter implementations not use wb_terms table
- T198868: Do not get entity data from wb_terms when "prefetching" data for displaying on pages
- T199833: wb_terms contains invalid UTF-8 data
- T198866: Uses of wb_terms SQL table to be migrated away from
- T142691: [Bug] wb_terms table truncates labels exceeding 255 bytes, possibly leaving invalid UTF-8 - This will technicaly not be an issue, as we won't be using wb_terms, but this could re surface with the new schema
- T197076: Collect list of variants used when display item or property