You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@age.apache.org by GitBox <gi...@apache.org> on 2022/03/18 20:42:43 UTC

[GitHub] [incubator-age] audiBookning edited a comment on issue #195: Variable Length Edges feature does not scale well with the length of the path

audiBookning edited a comment on issue #195:
URL: https://github.com/apache/incubator-age/issues/195#issuecomment-1072779272


   I am not sure if i understand correctly the situation, but i will add my two cents dependent only on my limited knowledge. Corrections are welcome.
   
   > I need first match and stop processing
   
   I also am not aware of anything like this in OpenCypher or even Neo4j's Cypher implementation. From my understanding, that type of operation, although useful in certain cases, wouldn't make sense in the "semantics" of OpenCypher which is one of the main "inspiration" for AGE.
   
   I will expand a little bit on the meaning of what i have just written.
   OpenCypher, as a language, focuses on patterns to describe and traverse graphs. It is, in my opinion, one of its best qualities compared to others approach's. But with advantages comes disadvantages and, for example, one shouldn't easily confuse pattern matching with paths on the graph.
   
   There is, at most, a relation of set (collection, list, ...) of paths to one pattern here. And that is, us, outside of the algorithm, trying to reason with it. But the fact is that we preferably shouldn't be concerned by its "internal" implementation (abstraction...).
   
   All of this means that there really is not a syntax for an individual path in Cypher, only of patterns. And only in the final results, output, can you really "see" individual paths. So when modelling our "problem", one should try to describe it (and solve it) with patterns, not individual paths.
   Cypher does have a shortest path function, but (not even considering the complexity of the problem) we enter in a very different area here.
   
   There is also an old rule to indicates that one should never treat a collection as if was an item or vice versa. This avoids many weirds and unexpected behaviours in algorithms. I have seen many people subconsciously do it.
   
   I think that changing this "pattern first semantic" (although not the only part of the language) would be basically going completely outside of Cypher. I am not part of AGE's dev group, but i imagine that it shouldn't be a decision to easily justify.
   
   I have not enough info, but your specific use case may be considered as an anti-pattern. You might be able to do something similar in OpenCypher with User-defined functions (or not, i have not experimented with it...). In AGE the most similar thing to it may be creating you own extension to AGE.
   A "cheaper" alternative could be using sql functions hooking on AGE, you would have to almost recreate the functionality of age in the worst case or, if using it as a kind of constraint (if the hooks exist, that is), it may be extremely expansive in terms of performance, jumping back and forth between your function and AGE's code.
   
   If even with all of this, you still want to use Cypher (and think, as i do, that the alternatives "solutions" that i have given (or others) are not in any way satisfying) You might consider remodelling your graph models and queries to better conform to Cypher's approach and your business model.
   
   Here is a very good inspiration for that (and possibly for the varied length issue discussed here):
   [Video - Optimizing Cypher Queries in Neo4j](https://vimeo.com/84900121)
   [Slides- Optimizing Cypher Queries in Neo4j](https://www.slideshare.net/neo4j/optimizing-cypher-32550605)
   
   > Sometimes it is not the tool that is wrong for the problem, but the way we use it.
   
   Random thoughts 😎.
   This issue reminds me of wikipedia's great gif explaining Djikstra's Shortest Path algorithm [Dijkstra_Animation](https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm#/media/File:Dijkstra_Animation.gif) and also of the Traveling Salesman problem (if you solve it, you probably would be an automatic millionaire and remembered in history as an incomparable genius).
   These last lines just to shows how much this issue can be complex and confusing...


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@age.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org