I am working on a use-case where it will be helpful if I could apply some bit-level operations on the VERSIONSTAMP_KEY (or VERSIONSTAMP_VALUE) placeholder bytes in my key/value (keeping the output length unchanged to make these operations simpler for fdb).
The operations I have in mind are things like
mask etc. only on the version_stamp portions of the bytes. Or to generalize, a function that takes 8 (or 10, if batching bytes can be made available) bytes as input and returns back 8 bytes post-transformation.
This opens up the possibility to come up with very creative uses of already versatile SET_VERSIONSTAMPED_KEY/SET_VERSIONSTAMPED_VALUE options! Note that these are not just optimizations (like predicate pushdown), but rather create options that were not at all possible earlier.
Do you think there is anything that is fundamentally wrong with this suggestion/approach? I believe that all the keys and values are completely filled up before giving them to resolver; so in this case, the proxy would apply these transformations when filling up the version_stamp in key or value and from that point on there should be no other change that would be needed.
If the above thinking makes sense, then how would one “pass” these transformations to fdbserver process? I am not suggesting these to be completely dynamic transformations that are decided at run-time; if there was a possibility of an interface/contract that one could implement, compile and provide to fdbserver as dynamically linked lib, and then mention the identifier of the transformation as part of key_value operation, would this be doable? We can even prohibit passing any runtime parameters to these transformations if it makes things more tractable. I am not at all good with C++ concepts related to this aspect, and hence doing a lot of hand-waving