For reverse edges, we want to store the UID lists on the same worker.
There are different ways of keying this.
Normal keys look like:
attr&len + byteData + UID
One possibility is:
attr&len + byteReverse + UID
Another possibility is:
modifiedAttr&len + byteData + UID
For the second option, I think most of the backend does not need to care whether this is a reverse edge or not. I like it for this reason. The modification of the attr could be pred → !pred for example. The not-so-nice thing is that there will be a few places where we need to detect that this is a “reverse attribute” and use the correct worker / “do the right thing”.
I want to us to remain clear about what’s data and what’s derived data. Mixing them up causes many problems later. We have a good system in place for indexing data – and for the most part, I don’t see reverses as anything more than indexing.
The only reason to keep them a bit separate is because our current tokenizers work on values, while reverses would work on uids.
I think the first possibility fits into our existing model well; so I’d advice using that. Also, another idea for how to represent reverses in GraphQL±, is to use bitwise complement operator ~. This is different from negation operator !, as explained in this wiki section: