mobrovac added a comment. In https://phabricator.wikimedia.org/T116247#1752974, @Ottomata wrote:
> I'm still a little confused about how this reqid/id will work? You are > suggesting that it comes from the x-request-id that we want varnish to set, > right? Won't this mean that multiple events (those produced during the same > http request at varnish level) will have the same reqid? That's the idea, yes, so that different requests that fire off in the system can be tied to the same request ID. In https://phabricator.wikimedia.org/T116247#1752975, @Ottomata wrote: > To avoid possible conflicts, I'd suggest we call this not just `id`. How > about `uuid`? That's what EventLogging capsule does: > https://meta.wikimedia.org/wiki/Schema:EventCapsule I don't see a conflicting problem with `id` (even though `id` is a JSONSchema keyword, but it relates to the schema, not its properties, so we're good there). `uuid` is not a good choice, IMHO, it's like naming a field //string// because its value is a string. The most accurate name would be `reqid`, since that's what it is. In https://phabricator.wikimedia.org/T116247#1752979, @Ottomata wrote: > Also, this is just a personal preference, but I'd prefer if we had a > convention differentiating integer/second based 'timestamps' and string/date > based 'datetimes'. For webrequest data, the ISO8601 is called `dt`. That can be seen from the fields type, I guess: if it's integer, it's a unix time stamp, otherwise an ISO8601 date. But I see your point. Will `s/ts/dt/` in the description. In https://phabricator.wikimedia.org/T116247#1753027, @Ottomata wrote: > Also, over at T88459#1694274 > <https://phabricator.wikimedia.org/T88459#1694274>, I commented: > > If we adopt a convention of always storing schema name and/or revision in the > schemas themselves, then we can do like EventLogging does and infer and > validate the schema based on this value. This would especially be helpful in > associating a message with an Avro Schema when serializing into binary. I'd be in favour of that as well. Two ideas: - Manual schema versions. We could increase the schema version every time we change something in the schema. Easy to achieve but it's also easy to forget to bump the version when something has been changed. - Use the git commit SHA1. Here the event bus would attach the current git commit SHA1 to the message. Also rather straightforward to achieve. The problem here might be that different messages for the same topic might have different SHA1's, but still point to the same version of the schema. TASK DETAIL https://phabricator.wikimedia.org/T116247 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mobrovac Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
