mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [mesos] cf-natali commented on pull request #386: Fixed a LevelDBStorage bug where positions would overflow.
Date Wed, 26 May 2021 22:45:26 GMT

cf-natali commented on pull request #386:
URL: https://github.com/apache/mesos/pull/386#issuecomment-849169050


   > @cf-natali @bmahler It strikes me that no backward conversion (from the string key
to an integer position) is ever used by the replicated log code.... Do we have a good understanding
what the actual contract for `encode()` should look like?
   > 
   > From what I can tell by quickly looking at the code, the main requirement is that
`encode()` results, when ordered lexicographically, should be in the order of positions. This
means that, **_if I haven't missed something_**, for example, prefixing integers larger than
`9'999'999'999` by a single letter `A` will result in the correct order of keys:
   > 
   > ```
   > 0000000000
   > .......
   > 9999999998
   > 9999999999
   > A00000010000000000
   > A00000010000000001
   > ```
   
   Nice!
   Indeed, that's also my understanding, as far as I can tell the only properties needed for
`encode()` are that it is:
   - bijective
   - monotonic - the ordering is checked using `leveldb::BytewiseComparator`, which does a
lexicographic comparison, see https://github.com/google/leveldb/blob/f57513a1d6c99636fc5b710150d0b93713af4e43/util/comparator.cc#L28
and https://github.com/google/leveldb/blob/5d94ad4d95c09d3ac203ddaf9922e55e730706a8/include/leveldb/slice.h#L100
   
   So yes, it looks like this could work - I'll have a play.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



Mime
View raw message