daniel added a comment.

  In https://phabricator.wikimedia.org/T107595#2250053, @GWicke wrote:
  
  > Some notes:
  >
  > - PageUpdater aims to provide similar functionality as the change 
propagation service (using EventBus) & the job queue. Could you clarify why we 
need another mechanism for change propagation?
  
  
  Where do I propose another mechanism for change propagation? The PageUpdater 
would do exactly what Revision does now: schedule DataUpdates. This can easily 
be changed to use EventBus at some point. PageUpdater (and possibly 
RevisionUpdater) are the "interactors" that bind updates to the storage layer 
to notificatiosn on the event bus. They don't implement a new mechanism. For 
now, they would do exactly what Revision already does.
  
  > - The blob store does not provide any locality information (title or page 
id, revision, render id / time-uuid), which means that it is incompatible with 
existing storage systems like RESTBase. Since locality information is critical 
for consistency and decent compression, I would suggest always providing at 
least these keys.
  
  The bob-store is (potentially) content-adressable, so the same blob may be 
used for different revisions of different pages. Even for blobs that have an 
incremental ID (e.g. using the current text table storage mechanism), the same 
blob would frequently be used for multiple blobs of the same page.
  
  Information like hash, timestamp, revision, etc would be associated with the 
revision_slot entry. The "slot" is the glue between the revision and the blob, 
and holds all relevant information for using the blob, including the content 
model and serialization format.
  
  I have been thinking about a mechanism that allows at least some 
meta-information to be associated with blobs, such as the length, hash, model, 
and format (but never the revision, since there may be any number of 
revisions). The problem is that not all storage mechanism support it (the text 
table only has an id, the blob, and some flags), so this would have to be 
optional.

TASK DETAIL
  https://phabricator.wikimedia.org/T107595

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, 
Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, 
Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, 
Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, 
Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808



_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to