Use decoded hex string when calculating the keyspace ID#9277
Merged
deepthi merged 4 commits intovitessio:mainfrom Nov 29, 2021
Merged
Use decoded hex string when calculating the keyspace ID#9277deepthi merged 4 commits intovitessio:mainfrom
deepthi merged 4 commits intovitessio:mainfrom
Conversation
6d5e75d to
b92b7dc
Compare
Member
Author
|
Example vindex function results from 11.0 before we started normalizing hex values (after this PR main produces the same results): |
c2ec4d6 to
ac36806
Compare
c9195fd to
133b0b1
Compare
f5672be to
ea394c9
Compare
a5aeaa6 to
61cb238
Compare
frouioui
approved these changes
Nov 24, 2021
Member
There was a problem hiding this comment.
It looks good to me! :)
Before merging, let's see if 61cb238 resolves @harshit-gangal 's comment
5f2d970 to
55dcac1
Compare
Member
Author
|
Here's a full user test: Results: |
This is done by properly managing the HexVal BindVar: - The "raw" value is what was seen in the query - The ToBytes value returns they bytes that mysql would return Signed-off-by: Matt Lord <mattalord@gmail.com>
Signed-off-by: Matt Lord <mattalord@gmail.com>
This is needed as with full hex value support we may need to escape the hex value string which can produce an error. Signed-off-by: Matt Lord <mattalord@gmail.com>
55dcac1 to
7682930
Compare
Signed-off-by: Matt Lord <mattalord@gmail.com>
7682930 to
55568d4
Compare
Collaborator
|
Very well-written description. Thank you for taking the time to write it up along with the code changes. |
3 tasks
mattlord
pushed a commit
to planetscale/vitess
that referenced
this pull request
Nov 29, 2021
Use decoded hex string when calculating the keyspace ID Signed-off-by: Matt Lord <mattalord@gmail.com>
This was referenced Feb 2, 2022
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This is a follow-up to #9118
There we normalized the incoming
x'A1'or0xA1string literal token that represents binary data as hex so that we can pass it on to MySQL as a BindVar.However, this means that when calculating the Keyspace ID in the vindex functions we need to decode the value again (as we do when parsing the incoming query) so that we're doing the keyspace range check using a decoded representation of the bytes that end up being stored in the column in MySQL.
This is accomplished here and here by properly managing the HexVal and HexNum BindVars:
Value.val/Value.Raw()and its variants) is "internal" and represents what was seen in the SQL query (e.g.x'997902'or0x997902)Value.ToBytes()) returns the bytes that mysql would return when querying the column (e.g.�y).For example:
We then see the exact same results for the vindex functions using the
x'A1'format seen before normalizing hex values.🆕 With this PR we also add support for using the
0xA1format with vindexes which did NOT work before:11.0:
This branch:
So now for vindexes we are properly treating
x'A1'and0xA1as equivalent. This is proper because while the string literal in the SQL query differs the same bytes are stored in MySQL for both. You can see a complete user test here.Related Issue(s)
Fixes: #9275
Checklist