Representing signed integers

[djMax]

(I'm not a CoffeeScript guy, so maybe I missed something reading the code). From the FoundationDb docs:

Integers

The standard tuple layer provides an order-preserving, signed, variable length encoding.
For positive integers, a big-endian fixed length encoding is order-preserving.
For signed integers, a big-endian fixed length two’s-complement encoding with the most significant (sign) bit inverted is order-preserving.

This would seem to imply the fdboost encoder should "do work" to encode integers in an order preserving fashion. I don't see that happening.

[ashbrener]

You are correct, since our use case for building encoding into this module was initially for storing strongly typed values in the KV.value, we were not overly focused on preserving lexicographical ordering.
It does make sense however to do this and I have borrowed some code from the FDB tuple module to resolve this for integers (up to 54bit - which should fix #1).

We then need to address ordering for doubles and datetimes.

What also concerns me is that the first byte of each encoding type is the type code. Assuming each type code never changes, I'm guessing its fair to assume that the type code prefix will then be mute in the ordering of like types (?)

[ashbrener]

Here's the commit 6720127