GWicke added a comment.
I went ahead and updated the task description with the current framing /
per-event schema. I renamed the `reqid` to just `id`, and added a `ts` field
containing the same timestamp in ISO 8601 format.
TASK DETAIL
https://phabricator.wikimedia.org/T116247
EMAIL PREFER
GWicke edited the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T116247
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: GWicke
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke,
mobrovac, MZMcBride, bd808, JanZe
GWicke added a comment.
> Right, but how would you do this in say, Hive? Or in bash? Timestamp logic
> should be easy and immediate.
Yeah, Hive really seems to be lacking built-in support for UUIDs. There seems
to be UDF code to deal with them, but it's definitely not as convenient as it
coul
Ottomata added a comment.
Right, but how would you do this in say, Hive? Or in bash?
Timestamp logic should be easy and immediate.
> Regarding a separate timestamp in the framing information: Which time would
> this correspond to?
This is up to the producer, I think. If there are more times
Eevans added a comment.
In https://phabricator.wikimedia.org/T116247#1748095, @Ottomata wrote:
> > So the producer would store the same time stamp twice? UUID v1 already
> > contains it.
>
>
> Could you provide an example of what this UUID would look like?
>
> A reason for having a timestamp onl
JanZerebecki added a comment.
As long as a separate public suppression event exists that refers to the old
one it sounds fine.
TASK DETAIL
https://phabricator.wikimedia.org/T116247
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: JanZerebecki
Cc: EB
gerritbot added a comment.
Change 248372 merged by jenkins-bot:
Fix undefined `last_session_ids=` method exception
https://gerrit.wikimedia.org/r/248372
TASK DETAIL
https://phabricator.wikimedia.org/T114368
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Sjoerddebruin added a subscriber: Sjoerddebruin.
Sjoerddebruin added a comment.
Can confirm.
TASK DETAIL
https://phabricator.wikimedia.org/T114586
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sjoerddebruin
Cc: Sjoerddebruin, Aklapper, Stryn, Wiki
jcrespo moved this task to Backlog on the Database workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T116404
WORKBOARD
https://phabricator.wikimedia.org/project/board/1060/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jcrespo
Cc: aude, da
hoo moved this task to monitoring on the Wikidata workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T116404
WORKBOARD
https://phabricator.wikimedia.org/project/board/71/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jcrespo, hoo
Cc: aude,
hoo added subscribers: daniel, aude.
hoo added a project: Wikidata.
hoo set Security to None.
TASK DETAIL
https://phabricator.wikimedia.org/T116404
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jcrespo, hoo
Cc: aude, daniel, hoo, Aklapper, jcrespo,
GWicke added a comment.
@JanZerebecki: Suppression information would indeed be needed for public access
to older events. One option would be to key this on the event's UUID. We could
also consider superseding the message using Kafka's deduplication (compaction)
based on the same UUID.
TASK DE
GWicke added a comment.
@ottomata, UUIDs are described in
https://en.wikipedia.org/wiki/Universally_unique_identifier. An example for a
v1 UUID is `b54adc00-67f9-11d9-9669-0800200c9a66`. There are libraries to
extract the high-resolution timestamp for most environments.
Regarding a separate ti
gerritbot added a comment.
Change 248372 had a related patch set uploaded (by Dduvall):
Fix undefined `last_session_ids=` method exception
https://gerrit.wikimedia.org/r/248372
TASK DETAIL
https://phabricator.wikimedia.org/T114368
EMAIL PREFERENCES
https://phabricator.wikimedia.org/setting
GWicke added a subscriber: EBernhardson.
TASK DETAIL
https://phabricator.wikimedia.org/T116247
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: GWicke
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke,
mobrovac, MZMcBride, bd808,
ReleaseTaggerBot added a project: WMF-deploy-2015-10-27_(1.27.0-wmf.4).
TASK DETAIL
https://phabricator.wikimedia.org/T116185
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ReleaseTaggerBot
Cc: JanZerebecki, aude, Aklapper, Wikidata-bugs, Deskana, je
ReleaseTaggerBot added a project: WMF-deploy-2015-10-27_(1.27.0-wmf.4).
TASK DETAIL
https://phabricator.wikimedia.org/T114368
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: dduvall, ReleaseTaggerBot
Cc: adrianheine, JanZerebecki, WMDE-Fisch, Jonas, T
ReleaseTaggerBot added a project: WMF-deploy-2015-10-27_(1.27.0-wmf.4).
TASK DETAIL
https://phabricator.wikimedia.org/T116381
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude, ReleaseTaggerBot
Cc: gerritbot, aude, Aklapper, Wikidata-bugs, Deskana,
JanZerebecki added a comment.
If we offer public access to the public events of the past we need to rewrite
them according to new events that hide previous public events. Can you make
sure that events that hide any part of previous public events are also public?
So that a public archive of even
gerritbot added a comment.
Change 248353 merged by jenkins-bot:
Browser tests: using mw_selenium 1.5 because 1.6 is broken
https://gerrit.wikimedia.org/r/248353
TASK DETAIL
https://phabricator.wikimedia.org/T114368
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpre
aude closed this task as "Resolved".
aude removed a project: Patch-For-Review.
TASK DETAIL
https://phabricator.wikimedia.org/T116381
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude
Cc: gerritbot, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb
aude moved this task to Done on the Wikidata-Sprint-2015-10-13 workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T116381
WORKBOARD
https://phabricator.wikimedia.org/project/board/1551/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude
Cc:
gerritbot added a comment.
Change 248345 merged by jenkins-bot:
Add --forceParse UpdaterFlag and option in forceSearchIndex script
https://gerrit.wikimedia.org/r/248345
TASK DETAIL
https://phabricator.wikimedia.org/T116381
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/
gerritbot added a comment.
Change 248353 had a related patch set uploaded (by Sbisson):
Browser tests: using mw_selenium 1.5 because 1.6 is broken
https://gerrit.wikimedia.org/r/248353
TASK DETAIL
https://phabricator.wikimedia.org/T114368
EMAIL PREFERENCES
https://phabricator.wikimedia.org
JanZerebecki added a comment.
In https://phabricator.wikimedia.org/T95686#1746797, @Ricordisamoa wrote:
> In https://phabricator.wikimedia.org/T95686#1746565, @JanZerebecki wrote:
>
> > The JSON serialization for items in the db will not change
>
>
> I suppose it will change for new edits, won't
aude added a comment.
the patch that adds the --justMapping option got split up into two patches, one
that adds the option to the script, and the second patch for "allowing mapping
customization with numeric fields"
this is the patch that adds the option:
https://gerrit.wikimedia.org/r/#/c/247
Ottomata added a comment.
> topics named something like mw-edit and mw-edit-private perhaps (where the
> latter contains this extra info).
I'd prefer if we did this the other way around. The 'private' topic will have
more data and be the main source of truth. The public one will contain a
s
Ottomata added a comment.
> So the producer would store the same time stamp twice? UUID v1 already
> contains it.
Could you provide an example of what this UUID would look like?
A reason for having a timestamp only field is so that applications can use it
for time based logic without having t
aude moved this task to Review on the Wikidata-Sprint-2015-10-13 workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T116381
WORKBOARD
https://phabricator.wikimedia.org/project/board/1551/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude
C
aude claimed this task.
aude added a project: Wikidata-Sprint-2015-10-13.
aude set Security to None.
TASK DETAIL
https://phabricator.wikimedia.org/T116381
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude
Cc: gerritbot, aude, Aklapper, Wikidata-bug
gerritbot added a project: Patch-For-Review.
TASK DETAIL
https://phabricator.wikimedia.org/T116381
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: gerritbot
Cc: gerritbot, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb
gerritbot added a subscriber: gerritbot.
gerritbot added a comment.
Change 248345 had a related patch set (by Aude) published:
Add --forceParse UpdaterFlag and option in forceSearchIndex script
https://gerrit.wikimedia.org/r/248345
TASK DETAIL
https://phabricator.wikimedia.org/T116381
EMAIL
aude added a comment.
even forceSearchIndex.php does not result in coodinates added for a cached page
:(
TASK DETAIL
https://phabricator.wikimedia.org/T116381
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude
Cc: aude, Aklapper, Wikidata-bugs, D
aude created this task.
aude added a subscriber: aude.
aude added projects: Wikidata, CirrusSearch, MediaWiki-extensions-GeoData.
Herald added a subscriber: Aklapper.
Herald added a project: Discovery.
TASK DESCRIPTION
When updating a page, CirrusSearch attempts to get ParserOutput from
ParserC
mobrovac added a comment.
In https://phabricator.wikimedia.org/T116247#1747924, @Ottomata wrote:
> I'd like an actual timestamp to be part of the framing for all events too.
> I'm all for a reqid, (although I'd bikeshed about the name a bit), but having
> a standardized canonical timestamp in
Ottomata added a comment.
I'd like an actual timestamp to be part of the framing for all events too. I'm
all for a reqid, (although I'd bikeshed about the name a bit), but Having a
standardized canonical timestamp in all events is very useful. Can we add:
- **ts**: iso 8601 timestamp. This m
aude created this task.
aude added a subscriber: aude.
aude added projects: Wikidata, MediaWiki-extensions-WikibaseRepository.
Herald added a subscriber: Aklapper.
TASK DESCRIPTION
Think this is not as high priority, but we could also set the 'country'
parameter for coordinates that Wikibase ad
aude created this task.
aude added a subscriber: aude.
aude added projects: Wikidata, MediaWiki-extensions-WikibaseRepository.
Herald added a subscriber: Aklapper.
TASK DESCRIPTION
We could also set the 'name' parameter in Coord objects when Wikibase adds
coordinates to GeoData.
unfortunat
38 matches
Mail list logo