Is it possible (or useful) to fetch the last key?

The default upper bound of ranges in Python bindings is b'\xFF'. If there is another key that is bigger, like b'\xFFFF' it will be not be returned by transaction.get_range(begin=None, begin=None) basically, using the current high level API there is no way to retrieve the whole database in a reliable way. Is that correct?

One way to work around is to prefix all keys with \x00 or use the tuple module.

Also, what is the purpose of the strinc function in the python bindings. Here is its definition:

def strinc(key):
    key = key.rstrip(b'\xff')
    if len(key) == 0:
        raise ValueError('Key must contain at least one byte not equal to 0xFF.')
    return key[:-1] + six.int2byte(ord(key[-1:]) + 1)


The \xff key-space is reserved for system use, and therefore shouldn’t be used by a client under normal circumstances. However, there are transaction options which grant read-only and full access to the system keys, should you need them. See set_read_system_keys and set_access_system_keys in our documentation.

The strinc function is designed to produce the key that serves as the exclusive upper-bound for all keys prefixed by the argument. In other words, it is the first key for which the argument is not a prefix. For example, if you call strinc(banana), the result will be bananb. There is no such key for any argument that contains only 0 or more \xff bytes, which is the reason for the error condition.

1 Like

I’ll also add that the system key-space ends at \xff\xff, so there are no keys in the database beyond that. However, there are some special “magic” keys that begin with \xff\xff which can be read on the client to yield various information, and don’t require any special options to access. For example, the key \xff\xff/connection_string returns the contents of the cluster file on the client. Another useful one is \xff\xff/status/json to get status information from a client. Sadly, I don’t think there’s one place that documents all of these, but that’s probably something we should try to do. You can see here and here for the documentation of the ones listed above.