[Lock] Better key naming when possible #60526
Conversation
|
I'm not sure how to test this change, any feedback/tips are welcome! |
|
This creates collisions for keys, as a long key is not considered the same resource than its hash. |
There was a problem hiding this comment.
I'm not sure I see what you mean @stof, can you please expand a bit?
Is there a reasonable case where the key could contain something binary? Shouldn't we hash it when it happens?
|
@stof May you please elaborate on your comment?
Before this change, collisions were possible if two keys shared the same hash (very unlikely, but still possible). With this change, collisions are possible if:
Was your comment about this last point? |
|
@sylfabre yes, my comment is indeed about that point. |
|
Thanks @stof I changed the PR
This prevents a 64-character plain string from colliding with a hashed large string. This addresses the issue you pointed out, right? |
Use plain text for key name when they are short enough. It helps to understand where inserted locks come from when looking at the database.
|
Thanks @OskarStark for spotting the typos 👍 |
Use plain text for key names when they are short enough.
It helps to understand where inserted locks come from when looking at the database.
See #57906 for examples of how the locks look like in the database.