thiemowmde added a comment.
I agree this would be cool, and I was thinking about this multiple times. I was not able to come up with something obvious. I mean, it's quite trivial to say "the hash of a StringValue is just the SHA1 of the string". But how would you document this for every slightly mo
Smalyshev added a comment.
It would be nice if we could make hashes at least reproducible by other tools... Though it might be non-trivial I admit. But now if some tool wants to generate RDF representation of Wikidata statement, there's basically no way besides using the same PHP code.TASK DETAILht
thiemowmde added a comment.
You did not answered my question. Sure, class names are implementation details and should not be in the hash calculation. But as the hash calculation is right now, these details are actually the most stable ones. Other details are much more likely to change – like us dis
daniel added a comment.
Yes, we do do this, e.g. https://gerrit.wikimedia.org/r/#/c/353022/. And every time we do this, the RDF database has to be re-imported. I cannot be avoided completely, but the risk can be reduced.
But there's also a conceptual reason beyond the practical one: Conceptually,
thiemowmde added a comment.
we can stop using hashes as identifiers for references.
If we find a way to do this without breaking everything, sure. Your suggestion sounds good. I can try to spend some time on this.
Perhaps we can make these hashes more stable, so they no longer depend on things li
daniel added a comment.
@thiemowmde we can't sensibly make the hashes completely stable. But we can stop using hashes as identifiers for references. The RDF mapping still uses hashes to identify data values - still a problem, but not as big. Perhaps we can make these hashes more stable, so they no
thiemowmde added a comment.
I might be ignorant, but is the problem really that big that it deserves that much attention? All we need to do is to be aware of it (which we are now after the incident you are referring to) and repopulate the #wikidata-query-service database when we think we need to ch
Smalyshev added a comment.
I don't know what you are talking about. As I already explained above we do have tests in place that make sure we are never changing hash calculations without being aware of it.
And yet, it recently changed without any announcement and I spent significant time trying to
thiemowmde added a comment.
if it's the last time.
It will never be "the last time". Right now the PHP class names are actually the most stable element in the hash calculation. All other details in there are much more likely to change the hash. Absolute stability can only be achieved by replacing
Smalyshev added a comment.
I'm going to close this ticket for now because it is not actionable and there is nothing we can do for now, except breaking all hashes again, which is what this ticket actually aims to avoid.
I'd be OK with breaking the hashes one more time, if it's the last time. Becaus
daniel added a comment.
I see no good way to do that. I would rather get rid of it entirely, and use uuids.TASK DETAILhttps://phabricator.wikimedia.org/T167759EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: daniel, Aklapper, Smalyshev, GoranSMilovano
Smalyshev added a comment.
Don't we still want to make the hash stable, at least for the future?TASK DETAILhttps://phabricator.wikimedia.org/T167759EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: daniel, Aklapper, Smalyshev, GoranSMilovanovic, QZa
daniel added a comment.
@Smalyshev after what we found yesterday, can this be closed?TASK DETAILhttps://phabricator.wikimedia.org/T167759EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: daniel, Aklapper, Smalyshev, GoranSMilovanovic, QZanden, EBjune,
Smalyshev added a comment.
Currently the code produces 9a24f7c0208b05d6be97077d855671d1dfdbc0dd but somewhere in April it still produced the old value. Not sure what changed.TASK DETAILhttps://phabricator.wikimedia.org/T167759EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpr
14 matches
Mail list logo
