You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unodb has a method to encode the user specified key type according to lexicographic ordering as unsigned byte[]s. This issue is to provide decode for that encoding. The decode is motivated by the desire to implement iterators that can visit the keys and values stored in the index. Since the index stores encoded values, a decode is required.
For many kinds of keys, it is possible to encode to lexicographic ordering and decode without information loss. However, this is not true for all key types. In particular, Unicode poses a variety of interesting challenges (locale, sort keys, etc.) and can not be decoded.
To handle simple key types, the application can specify an information preserving encode and decode.
To handle general keys for including variable length data and Unicode data, the application needs to own the encoding and would specialize Unodb for variable length byte[]s. Those keys would have a NOP encoding and decoding and the application would encode inbound and own responsibility for dealing with the encoded keys outbound for those cases where the information is reversible.
The text was updated successfully, but these errors were encountered:
Partially resolved. Code in master handles all signed and unsigned integers. It does not yet handle floating point keys or fixed width lexicographer successors.
Unodb has a method to encode the user specified key type according to lexicographic ordering as unsigned byte[]s. This issue is to provide decode for that encoding. The decode is motivated by the desire to implement iterators that can visit the keys and values stored in the index. Since the index stores encoded values, a decode is required.
For many kinds of keys, it is possible to encode to lexicographic ordering and decode without information loss. However, this is not true for all key types. In particular, Unicode poses a variety of interesting challenges (locale, sort keys, etc.) and can not be decoded.
To handle simple key types, the application can specify an information preserving encode and decode.
To handle general keys for including variable length data and Unicode data, the application needs to own the encoding and would specialize Unodb for variable length byte[]s. Those keys would have a NOP encoding and decoding and the application would encode inbound and own responsibility for dealing with the encoded keys outbound for those cases where the information is reversible.
The text was updated successfully, but these errors were encountered: