Reverse edges implementation

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”.

Any suggestions or opinions? Thanks. @core-devs

Hey @jchiu,

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:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.