Arangodb: Feature request: Non-shortest-path traversals use weight.

[teamrehab]

my environment running ArangoDB

I'm using the latest ArangoDB of the respective release series:

• [X ] 3.3
  Mode:
• [ ] Cluster
• [ X] Single-Server

Storage-Engine:

• [ ] mmfiles
• [ ] rocksdb
  ? Whatever is default.

On this operating system:

• [ X] Windows, version: 10 fall creators

this is an AQL-related issue:

[ X] I'm using graph features

I'm issuing AQL via:

• [x ] arangosh

Feature:

Being able to use the weight feature in a normal traversal would be amazing.
I brought it up here first. https://stackoverflow.com/questions/48553358/arangodb-weight-in-traverse-thats-not-shortest-path?noredirect=1#comment84182300_48553358

Some relationships (edges) might be more important than others.
Examples when it could be useful:

• All paths between friends & family, with a greater weight on family. Because it would make sense for those to come first in many lists. So if you are seeing all paths between friends, the weight would be: family, friends, co-workers, etc.
• For all directions between 2 points on a map may way to give greater weight to paved roads.

A few things to note:

• Yes, there may be non-deterministic results when two weights are the same at the same depth. But that doesn't really matter. Or there could be a secondary weight.
• Yes, you could accomplish this by a post sort on the path. But having this built into the original query would add efficiency, especially when limiting the results. Because if you did this with a sort on the path afterwards, you couldn't limit until after that. So you'd have to pull far more results on the initial query.
• To my knowledge, no other graphDB does this. So it would yet another reason to use Arango over the others.

Thank you for considering this.

[davidmw]

Many of the edges in my project have weights and I will often need to sort or filter results on the weights.

What weight scale should be used and what are the end points?

I'd not want to be forced to use a specific range (0 - 1, 1 - 10, Integers, etc). My project has about 5 different weight scales and it would be better to represent the weights naturally instead of mapping them to a common scale.

Some of my edge types have multiple weights and a single query may need to utilize more than one. One parameter represents connection strength and the other is importance / relevance. 'A' can be very strongly associated with 'B' but have a trivial impact on the result (not important) so shouldn't be t the top of the result list.

I do enthusiastically support the feature request since it could significantly reduce my query complexity.

[teamrehab]

Hi there. I was just checking to see if this was being considered for 3.4?

Thanks!

[undeadindustries]

I would really love to see traverse by weight.