[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Lucas_Werkmeister_WMDE added a comment. >> **Task description** >> >>> The special page currently always re-runs the constraint checks via WDQS, it does not get or set any cache. >> >> Why not? > > Sorry, it does set the cache, bur will not get the cache. I don’t think it

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. In T214362#6028271 , @Krinkle wrote: > **Task description** > >> The constrain checks are accessible via 3 methods: >> >> - RDF action >> - Special page >> - API >> >> […] The RDF page-action

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Krinkle added a comment. **Task description** > The constrain checks are accessible via 3 methods: > > - RDF action > - Special page > - API > > […] The RDF page-action exists for use by the WDQS and will not run the constraint check itself, it only exposes an RDF description

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

daniel added a comment. In T214362#5814559 , @Addshore wrote: > Yes, we need this! > This decision is one of the 2 rfcs blocking continued work on constraint checks for Wikidata that was started in either late 2018 or early 2019. :)

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. Yes, we need this! This decision is one of the 2 rfcs blocking continued work on constraint checks for Wikidata that was started in either late 2018 or early 2019. :) TASK DETAIL https://phabricator.wikimedia.org/T214362 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Lydia_Pintscher added a comment. We need this! :D (Seriously!) TASK DETAIL https://phabricator.wikimedia.org/T214362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: CCicalese_WMF, kchapman, Krinkle, mobrovac, abian,

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. I see that T227776 has had little activity since November, is there any way to move this forward? TASK DETAIL https://phabricator.wikimedia.org/T214362 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. In T214362#5363005 , @daniel wrote: > I'd be interested in your thoughts on T227776: Generalize ParserCache into a generic service class for large "current" page-derived data

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

daniel added a comment. In T214362#5338030 , @Addshore wrote: > In T214362#5324623 , @daniel wrote: > >> Most importantly, the proposal assumes the existence of a "more permanent

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. In T214362#5324623 , @daniel wrote: > Moved to the RFC backlog for improvement after discussion at the TechCom meeting. The proposed functionality seems sensible enough, but this ticket is lacking information

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

daniel added a comment. In T214362#5284886 , @Marostegui wrote: > Just a quick question: "this would fit a generalized parser cache mechanism" meaning it would fit into the existing parsercache mechanism (and infrastructure) or is that

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Marostegui added a comment. Just a quick question: "this would fit a generalized parser cache mechanism" meaning it would fit into the existing parsercache mechanism (and infrastructure) or is that still to be defined? Thanks! TASK DETAIL https://phabricator.wikimedia.org/T214362 EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

daniel added a comment. Side note: we discussed this use case at the CPT offsite. It seems like this would fit a generalized parser cache mechanism. This is something we will have to look into for the integration of Parsoid in MW core anyway, but it's at least half a year out, still. TASK

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. In T214362#5259988 , @daniel wrote: > @Addshore if you think no further discussion is needed and this is ripe for a decision, I'll propose to move this to last call at our next meeting. I'll put it in the RFC

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. Just poking this a few months down the line, as far as I know this still rests with #techcom for a decision if discussion has finished? TASK DETAIL https://phabricator.wikimedia.org/T214362 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. Just to be clear on this RFC regarding my above comment, we are not waiting for a reply from @Lydia_Pintscher here. The decision is to keep the behaviour for the user the same. This still allows us to only need to write to storage during POSTs and via the job

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Lucas_Werkmeister_WMDE added a comment. > and once we have data for all items persistently stored in theory the user would never ask for an items constraint check and it not be there (thus no writing to the storage on request) > Once the storage is fully populated this isn't even

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. In T214362#4970952 , @daniel wrote: > In T214362#4970942 , @Addshore wrote: > > > We can continue to generate constraint check data on the fly when missing

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

daniel added a comment. In T214362#4970942 , @Addshore wrote: > We can continue to generate constraint check data on the fly when missing in GETs and simply not put it in the storage. you could trigger a job in that case. the

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. I think we can easily have this only persist to the store via the Job or a POST. We can continue to generate constraint check data on the fly when missing in GETs and simply not put it in the storage. Once the storage is fully populated this isn't even a case

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Joe added a comment. In T214362#4967944 , @Addshore wrote: > > We currently still want to be able to compute the check on demand, either because the user wants to purge the current constraint check data, or if the check

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Addshore added a comment. In T214362#4954428, @Joe wrote: In order to better understand your needs, let me ask you a few questions: Do we need/want just the constraint check for the latest version of the item, or one for each revision? Currently there is only the need to store the latest

[Wikidata-bugs] [Maniphest] [Commented On] T214362: RFC: Store WikibaseQualityConstraint check data in persistent storage

Joe added a comment. In order to better understand your needs, let me ask you a few questions: Do we need/want just the constraint check for the latest version of the item, or one for each revision? How will we access such constraints? Always by key and/or full dump, or other access patterns can