Versioning of special key space

[ajbeamon]

@markus.pilman

If we ignore for a second that this feature already exists (and so some code already depends on this), I don’t think this is generally a very important feature. A layer can easily build abstractions around it.

There was some interesting discussion about this at Implementing VersionStamps in bindings - #7 by KrzysFR, and from that I gathered that the ability to access the versionstamp from a layer like this was something people cared about. It’s also worth noting that even the current get_versionstamp approach was causing some ergonomics issues there. Certainly it’s the case that we could build abstractions that would support being able to access this data, but if we decide to do something like this in the future I think it’s important to consider what these abstractions will actually look like and whether they are going to be unpleasant for the people writing and using them.

@markus.pilman

But to be a bit more formal, I propose that the following should be in this special key space:

1. Information about the status of the system - \xff\xff/status/json acts as precedence here (and it just makes sense). In the future I would like to give the clients also some access to some internal status (like read/write hot ranges, data distribution metrics etc). This is important for us as we do a lot of client side throttling.
2. Status about the client and about the transaction. Imho it makes sense to let a client for example access the read and write conflict sets through this. We also added the conflict sets there.
3. Configuration. IMHO for writing there should be a knob to guard against accidents. Configuration changes are done through transactions in fdb anyways, so a transaction object is imo the right place to add this. For reading one could argue this falls into the category above.

These all sound good to me. Out of curiosity, how do the conflict sets work? Do you need to read this space after the commit to get an answer? I’m ok with that approach, btw, at least until someone tells us if doesn’t work for them.

@markus.pilman

For now we version this keyspace as described in my original post. I think this makes sense as it is the most conservative way of versioning and therefore it will be possible to change in the future.

Sounds good.

@markus.pilman

1. Scanning across modules is a bit problematic as we didn’t define what module means (and everyone had some intuitive understanding). So I would propose the following (conservative) compromise:

For any query over a range [a, b) , it has to be true that:
(i) if \xff\xff is either a prefix of a and b or it is not a prefix of either.
(ii) If \xff\xff is in the range, there is a string x for which it holds that [a, b) is sompletely contained in the range ["\xff\xff/x/", "\xff\xff/x0")

So (i) basically says that you can’t query across normal and special key space and (ii) defines that your query has to be within a directory.

I think this sounds fine, though if we intend to restrict what’s in the space to the things in the list you described above and we aren’t blocking anything until post-commit, etc, then I feel less strongly that (ii) (or some alternative) is needed. It might be good to have if we expect our definition of what’s in here to change such that we might have to add this restriction later, though.