audiBookning commented on issue #195: URL: https://github.com/apache/incubator-age/issues/195#issuecomment-1072779272
I am not sure if 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 one its best qualities compared to others approach's. But with advantages comes disadvantages and, in this particular case, 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 a pattern here. And that is us, outside of the algorithm, trying to reason with it. But we shouldn't be concerned by its "internal" implementation (abstraction...). All of this means that there really is not a syntax for an individual path, 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
