Documentation for _all_ and _predicate_

I am trying to wrap my head around using predicate and all, but the minimal examples in the documentation don’t provide a lot of detail.

I understand how the examples provided work, but I don’t understand the following.

  1. Why is can predicate be expanded if it is saved as a variable first, but can’t be expanded in the form expand(_predicate_) which gives the following error - Invalid argument _predicate_ in expand()? In contrast, expand(_all_) works without being saved to a variable.
  2. Why do things like count and aliases not take affect on _predicate? Instead it acts just as if _predicate_ was the only statement on that line.
  3. Why does count(_all_) return 0?
  4. I guess the root question that got me exploring all of this, is there a way that I can get a count of how many predicates have been assigned to an entity? It would be very useful for scoring/ordering to be able to determine the overall “connectedness” of nodes/entities.

Thanks -

Hey @JustinJudd

  1. That’s a good question. expand(_all_) sounded better when we were developing it. But expand(_predicate_) seems like a good option too. We’ll see if we can change it.

  2. It’s still work in progess and has to be integrated with other features like count, alias, etc. You can expect it out soon.

  3. Same reason as 2.

  4. The idea behind _predicate_ is that it returns the union of all the predicates for the nodes at one level and not per node. So ordering the nodes using this in a single query isn’t supported as of now.

Thanks for the questions and feedback.

Thanks, for the reply, and especially for clarifying that _predicate_ is the union of all predicates for nodes at a given level. Is _all_ more or less just an alias for _predicate_, or would it contain just the predicates for a particular node?

Thanks -

Yes, it’s an alias. We went with expand(_all_) since it felt intuitive for expanding on all the edges.

Thanks again. Appreciate the quick support.

i love the “expand” feature! However, would it not make sense to also return the reverse edges?

Maybe it makes more sense to have: expand(forward), and expand(reverse), so the intention is clear.

1 Like

expand(all), expand(forward) and expand(reverse), that would be awesome!

@prange: Sounds like a good idea. If you add a Github issue, I’ll ensure it gets baked.

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