Pintoch added a comment.
I was thinking of the opposite: consider the violations related to the revision R of the item I to be the violations of the statements of I with respect to the state of Wikidata just before R+1 was saved.
Because for the current revision, you do want to keep invalidating t
Tpt added a comment.
Thank you @Pintoch for raising this idea. For my fixing constraints violations project, I can mine violations from history offline so I do not really need this feature.
About the vandalism detection (and maybe diffs) use case, what we could do and seems quite reasonable to me
Lydia_Pintscher added a comment.
Thanks a lot! That helps me understand it better and it definitely sounds awesome.
The problem is that not only the current item can be responsible for a violation. Violation causing and fixing on item X is not necessarily related to an edit on item X. Have you thou
Pintoch added a comment.
@Lydia_Pintscher personally here is what I would concretely implement in the EditGroups tool. For each edit that is part of an edit group:
fetch the constraints violations before and after the edit (this fetching would happen as the edit is retrieved, so in near real-time
Lydia_Pintscher added a comment.
@Pintoch: Sounds good. Could you explain a bit more how you'd use the data? And what data specifically so we can see if we can make it happen?TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailp
Lucas_Werkmeister_WMDE added a comment.
We primarily need a key-value store, yes: given an entity ID, get the constraints data for that entity.
However, that data also includes some metadata on the validity of the constraints data, specifically a set of other entity IDs with their latest revision
Jonas added a comment.
I am afraid getting accurate numbers about size is hard.
Storing the RDF should be no problem:
https://www.wikidata.org/wiki/Q42?action="">
If we want to store the JSON to be able to completely remove memcache we should be able to store something like this:
https://www.wiki
Smalyshev added a comment.
There is the possibility that we will need to provide dumps of all constraint violations in order to ease the loading of data into WDQS servers that are starting from scratch
If we plan to have permanent storage for it (not like now, load-on-new-edit model which ignores
Eevans added a comment.
In T204024#4576751, @daniel wrote:
This use case seems similar to caching parsoid HTML, which is done in RESTbase and backed by Cassandra. It's similar, because it's re-generated upon edit, and accessed from clients upon view, via an API. It's also similar in that losing th
daniel added a comment.
This use case seems similar to caching parsoid HTML, which is done in RESTbase and backed by Cassandra. It's similar, because it's re-generated upon edit, and accessed from clients upon view, via an API.TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShtt
Jonas added a comment.
+1 for Cassandra, but one disadvantage might be that normal installation don't have the service.TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: Jonas, Lucas_Werkmeister_WMDE, A
Addshore added a comment.
I have added this use case to the list of possible use cases for Cassandra, as storing the blobs in Cassandra instead of in SQL would make sense.TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailprefe
12 matches
Mail list logo
