| 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 discussing an entire rewrite of the hashing code.
So what details of the hash calculation do you, @daniel, consider especially unstable?
https://gerrit.wikimedia.org/r/353022 was a conscious decision. Yes, we made a mistake there by not realizing early enough that we had to rebuild the #wikidata-query-service database. But again, the change itself was a conscious decision and not some "accidental breakage" that happened "without any announcement".
The suggestion to let the RDF builder do it's own hashing that does not call any of the existing getHash functions might sound like a nice idea, for a moment. But it does have a series of major problems, which is why I decided to not spend time on this for now:
- It would be a quite large and fragile chunk of code that more or less duplicates what the Snak and DataValue classes already do.
- The custom hashing might be able to traverse Statements, Snaks, and DataValues, but at some point it must consider the actual values stored in the DataValue classes. This means this custom hashing must still break whenever the slightest change is made to a value, including the addition of fields – something we do not consider a breaking change. Overall this makes such a custom hashing as fragile as the original one.
Cc: thiemowmde, daniel, Aklapper, Smalyshev, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, JeroenDeDauw, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
