Hi!
> You can seek back on EventBus events, but not permanently (by default, only
> up to 1 week). If you want to respond to changes in an event stream, you
1 week is not enough for this use case, but if it could be extended to,
say, 1 month, that could be workable.
The reason is that the
You can seek back on EventBus events, but not permanently (by default, only
up to 1 week). If you want to respond to changes in an event stream, you
should consume the full event stream realtime and react to the events as
they come in. A proper Stream Processing system (like Flink or Spark
Hi!
> Could we emit a page/properties-change event to EventBus when page props
> are updated? Similar to how we emit an event for revision visibility
> changes:
This, however, still is missing a part because, as I understand,
EventBus is not seekable. I.e., if I have data up-to-date to
On Fri, Sep 23, 2016 at 9:25 AM, Andrew Otto wrote:
> Could we emit a page/properties-change event to EventBus when page props
> are updated?
I don't know how the event stuff works, but if you can do it by hooking
hooks then 'LinksUpdateComplete' would likely be the hook to
I like the idea of having a unique event for this sort of thing. There's a
large class of annotations like that that happen on a shifted timescale.
E.g. abuse filter tags are applied after an edit is saved. If we are to
build a queue of edits for review, we'd like to have up-to-date abuse
filter
Could we emit a page/properties-change event to EventBus when page props
are updated? Similar to how we emit an event for revision visibility
changes:
https://github.com/wikimedia/mediawiki-event-schemas/blob/master/jsonschema/mediawiki/revision/visibility-change/1.yaml
These events would be
Hi!
I'd like to raise a topic of handling change notifications and
up-to-date-ness of Wiki pages data with relation to page props.
First, a little background about how I arrived at the issue. I am
maintaining Wikidata Query Service, which updates from Wikidata using
recent changes API and RDF