fix-bug-when-scheam-version-greater-than-256 #4023
Conversation
|
Thx for contribution |
src/common/utils/MetaKeyUtils.cpp
Outdated
| SchemaVer MetaKeyUtils::getLatestEdgeVersion(kvstore::KVIterator* iter, folly::StringPiece& val) { | ||
| SchemaVer maxVer = MetaKeyUtils::parseEdgeVersion(iter->key()); | ||
| val = iter->val(); | ||
| if (maxVer >= borderScheVer) { |
There was a problem hiding this comment.
Actually I think maybe you need to iterate no matter what is in maxVer.
For example, if there are 0x7fffffffffffffff schemas (which is std::numeric_limits::max()), when we encode into rocksdb (see MetaKeyUtils::schemaEdgeKey), the bytes are 00 00 00 00 00 00 00 00 , and this will be the first schema since we use rocksdb in byte order, so parseEdgeVersion will return 0....
The root cause is that we encode numbers in little endian, which is not the same order of rocksdb in bytes order.
There was a problem hiding this comment.
Actually it is more like a math problem 😢 , I'm really not good at it...
There was a problem hiding this comment.
Agree with what critical27 said.
Or distinguish the endianness used.
Or traverse all the keys of the tagId and take the largest version.
The second is easier
There was a problem hiding this comment.
Good catch
The root cause is a sorting problem caused by little endian mode.
Take the int32_t value 255 or 256 as an example:
int32_t 255（0x000000FF）
int32_t 256（0x00000100）
The corresponding value in little endian mode
255: 0x FF 00 00 00
256 0x 00 01 00 00
The corresponding value in big endian mode:
255: 0x 00 00 00 FF
256 0x 00 00 01 00
The little endian mode we use, when sorted in ascending order in rocksdb,
The value 255 comes after only 256, (we would have expected 255 to be before 256)
src/common/utils/MetaKeyUtils.cpp
Outdated
| @@ -560,6 +560,24 @@ SchemaVer MetaKeyUtils::parseEdgeVersion(folly::StringPiece key) { | |||
| *reinterpret_cast<const SchemaVer*>(key.begin() + offset); | |||
| } | |||
|
|
|||
| SchemaVer MetaKeyUtils::getLatestEdgeVersion(kvstore::KVIterator* iter, folly::StringPiece& val) { | |||
There was a problem hiding this comment.
Maybe function name getLatestEdgeVersion needs to be rename.
Here, not only the maximum version is obtained, but the val corresponding to the maximum version is also obtained.
What type of PR is this?
What problem(s) does this PR solve?
Issue(s) number:
#3993
Description:
How do you solve it?
If the schema version got by doprefix is less than 255, just return. Otherwise, it will iterate all the schema belonging to the queried tag to find the largest one.
Special notes for your reviewer, ex. impact of this fix, design document, etc:
Checklist:
Tests:
Affects:
Release notes:
Please confirm whether to be reflected in release notes and how to describe: