JeroenDeDauw added a comment.
I was wondering about how much extra complexity the post request approach (4) would bring. In particular, which info do we need to give to the job. Giving the property id is not sufficient. You could give the ids of the text records and then in the job check if they are still unused and do the same for the higher level records that point to those text records. Thing is, if you already need to find the unused records in the request, then you can just as well delete them right away. Either way you have a performance penalty. So I think the simpler approach (immediate cleanup (3)) makes more sense as a starting point. Does that make sense to you? > As pointed out at some point we probably want to remove the strings from the table fairly sharpish, as content my be removed, revdeled, and should not continue to appear in public places such as labs dB replicas. Interesting. Treating our internal storage as public even when it can't be accessed via the software is kinda weird. People that have access to a replica can just log/copy everything anyway, so this is a bit of a half measure. From an architecture PoV I'd also prefer the persistence details to be private and to have well defined interfaces. That's for when we talk about the labs use case(s) though :) TASK DETAIL https://phabricator.wikimedia.org/T220150 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: Ladsgroup, Addshore, alaa_wmde, Aklapper, JeroenDeDauw, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
