Page MenuHomePhabricator
Create Task
Maniphest T225040

Check if filtering is needed in labs for new term store data
Closed, ResolvedPublic
Actions

Description

From parent task:

In T224403#5235258, @alaa_wmde wrote:

As far as I can see, wb_terms is listed in https://github.com/wikimedia/puppet/blob/production/modules/profile/templates/labs/db/views/maintain-views.yaml#L138, and there does not seem to be any column filtering setup on it in https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/role/files/mariadb/filtered_tables.txt.

This means our new schema tables will as well be configured to copy, without any column filtering, at least for the beginning.

Is that claim true? or do we need to filter anything?

Related Objects
Search...

StatusSubtypeAssignedTask
 ResolvedAddshoreT208425 [EPIC] Kill the wb_terms table
 ResolvedArielGlennT226167 audit public tables and make sure we dump them all
 ResolvedAddshoreT219175 [Mega] - Migrate data from wb_terms to new schema
 ResolvedAddshoreT219120 [Checkpoint 1] Create Schema, Migration plan and Doctrine DBAL connection
Resolved• alaa_wmdeT219142 Send the schema to DBAs and follow up with their review
 Resolved• alaa_wmdeT219143 Write DDL sql files for creating the schema
 Resolved• alaa_wmdeT220210 Create a script to generate lots of Items/Properties with lots of Terms
 ResolvedNoneT220230 Tailor a migration plan
 DeclinedNoneT220231 Migration Plan 2
 Declined• alaa_wmdeT219145 Migration Plan 1
 ResolvedLadsgroupT220480 Migration Plan 3
 ResolvedAddshoreT219121 [Checkpoint 2] Refactor Write & Migration code for Properties
 ResolvedLadsgroupT219294 Create interface for writing and deleting entity terms
 ResolvedJeroenDeDauwT219295 Create service for writing property terms
 DeclinedNoneT220169 Optimize term updating
 ResolvedNoneT219297 Adjust current write logic to write property terms to new schema
 ResolvedNoneT219894 Create maintenance script for migrating property terms to new schema
 ResolvedLadsgroupT219296 Update TermSqlStore to comply with EntityTermStoreWriter interface
 ResolvedNoneT220150 [Story] Clean up unused records
 InvalidNoneT221699 Introduce appropriate abstraction for clean up invocation in wikibase-term-store
 DeclinedNoneT221700 implement clean up logic in doctrine-term-store
 ResolvedLucas_Werkmeister_WMDET221701 implement clean up logic in MW DBAL store
 InvalidNoneT221703 add a job to wikibase to invoke clean up logic
 DeclinedNoneT221704 Update wikibase logic to queue a deferred update for cleanup after updating/delete terms in terms store
 ResolvedLadsgroupT221615 Make a test instance in cloud VPS to test new term store
 DeclinedNoneT219805 Investigate Doctrine DBAL usage possibility
 ResolvedJeroenDeDauwT220155 Implement Doctrine DBAL Driver Connection wrapper for MW db connection
 DeclinedNoneT221568 Improve MW connection access
 Resolved• alaa_wmdeT224269 Handle race-conditions between storage and cleanup logic
 ResolvedLucas_Werkmeister_WMDET225050 Update DatabaseItemTermStore and DatabasePropertyTermStore to use callback logic in DatabaseTermIdsAcquirer
 ResolvedLucas_Werkmeister_WMDET224504 Implement database-based PropertyTermStore
 ResolvedLucas_Werkmeister_WMDET224541 Update Wikibase entity saving logic to use PropertyTermStore
 ResolvedAddshoreT219122 [Checkpoint 4] Refactor Write & Migration code for Items
 ResolvedNoneT221564 Create maintenance script for populating new item term persistence
 InvalidNoneT224542 Update Wikibase entity saving logic to use ItemTermStore
 Resolved• alaa_wmdeT224527 Implement database-based ItemTermStore
 ResolvedLadsgroupT219123 Migrate to and read from new store for item terms
 InvalidNoneT221715 Implement ItemTermStore in mediawiki dbal lib
 DuplicateLadsgroupT225055 Switch `tmpItemTermsMigrationStages` to MIGRATION_WRITE_BOTH
 ResolvedLadsgroupT225056 Run Item Terms Rebuild script
 DuplicateLadsgroupT225057 Switch `tmpItemTermsMigrationStages` to MIGRATION_WRITE_NEW
 ResolvedLadsgroupT234329 Investigate, fix and reimport failing item terms into new store
 ResolvedLadsgroupT232393 Find out why rebuilding some items in new term store failed
 ResolvedLadsgroupT234948 New Wikibase deadlocks on Wikidata wiki since 2019-10-08T00:00:02: Wikibase\Lib\Store\Sql\Terms\{closure} Deadlock found when trying to get lock; try restarting transaction
 ResolvedAddshoreT235265 Slow query on SpecialMostLinked creating lag on wikidata slaves
 ResolvedAddshoreT239470 Check the success of the initial terms migration (does it have holes)
 ResolvedAddshoreT239471 Sqoop wikidata terms tables into hadoop
 ResolvedLadsgroupT240235 Alter rebuildItemTerms.php to allow passing of a a list of int item ids to process
 ResolvedAddshoreT245740 LUA getLabelWithLang calls result in many db queries to terms storage with spikey and unpredictable patterns
 ResolvedLadsgroupT246005 Wikibase client description API module results in 15k selected rows with new term storage
 ResolvedLadsgroupT246159 Setting on read new for items causes increased worst response time and number of open connections
 ResolvedLadsgroupT219301 Migrate to and read from new store for property terms
 ResolvedJun 17 2019• alaa_wmdeT224403 Update Labs replication and views to include new schema tables
 ResolvedNoneT225040 Check if filtering is needed in labs for new term store data

Event Timeline

• alaa_wmde created this task.Jun 4 2019, 11:56 PM
• alaa_wmde moved this task from Backlog to In Review on the Wikidata wb_terms Trailblazing board.Jun 4 2019, 11:59 PM
• alaa_wmde added subscribers: Lucas_Werkmeister_WMDE, WMDE-leszek, hoo.

@Ladsgroup @Lucas_Werkmeister_WMDE @hoo @WMDE-leszek @Addshore

Ladsgroup added a comment.Jun 5 2019, 9:43 AM

Given that wb_terms is also fully replicated I don't see any reason to change it now. We remove terms from the term store when the page gets deleted/suppressed etc.

Lucas_Werkmeister_WMDE added a comment.Jun 5 2019, 10:11 AM

I agree we don’t need to filter anything – terms that are no longer used in a latest revision are cleaned up almost immediately (currently as part of the edit transaction, but will probably move to a post-request handler or a job before production deployment), so if someone puts sensitive information in a term, removing it from the entity should be enough to remove it from the replicas as well, even before the old revision is deleted.

hoo added a comment.Jun 5 2019, 11:31 AM

I also don't see any reason to filter this, the current design is mostly equivalent to wb_terms which is also fully available (only public data is present).

Lucas_Werkmeister_WMDE closed this task as Resolved.Jun 5 2019, 11:33 AM
Lucas_Werkmeister_WMDE moved this task from In Review to Done on the Wikidata wb_terms Trailblazing board.
Lucas_Werkmeister_WMDE mentioned this in T224403: Update Labs replication and views to include new schema tables.Jun 5 2019, 11:49 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits