[jira] [Commented] (TINKERPOP-2522) DefaultTraversalMetrics::toString does not indent annotations correctly
[ https://issues.apache.org/jira/browse/TINKERPOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281635#comment-17281635 ] Boxuan Li commented on TINKERPOP-2522: -- I would love to contribute but cannot do it because Tinkerpop is not an approved project in my firm :( > DefaultTraversalMetrics::toString does not indent annotations correctly > --- > > Key: TINKERPOP-2522 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2522 > Project: TinkerPop > Issue Type: Bug > Components: process >Reporter: Boxuan Li >Priority: Major > > In > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/DefaultTraversalMetrics.java#L255,] > the indent parameter is not used when printing out annotations. That is, no > matter what the indentation level is, annotations are always indented the > same way. Looks like a bug to me. > I noticed this behavior in > [https://github.com/JanusGraph/janusgraph/pull/2410#issuecomment-770188509] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2523) Allow registration of listeners for traversal iteration begin/end events
Clément de Groc created TINKERPOP-2523: -- Summary: Allow registration of listeners for traversal iteration begin/end events Key: TINKERPOP-2523 URL: https://issues.apache.org/jira/browse/TINKERPOP-2523 Project: TinkerPop Issue Type: Improvement Components: server Affects Versions: 3.4.10 Reporter: Clément de Groc In order to improve observability/monitoring (e.g. distributed tracing, logging of traversals requests), it would be nice if users could register custom listeners for traversal iteration begin/end events. Those begin/end events are actually already nicely exposed as protected methods in [TraversalOpProcessor|https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L262-L272]. Though, in 3.4.10, it is difficult to subclass TraversalOpProcessor to override those methods as the [OpLoader|https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/OpLoader.java#L47] ensures only one OpProcessor can be loaded with name "traversal". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2523) Allow registration of listeners for traversal iteration begin/end events
[ https://issues.apache.org/jira/browse/TINKERPOP-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281877#comment-17281877 ] Alex Van Boxel commented on TINKERPOP-2523: --- It's well worth looking into [https://opentelemetry.io/] for this. It's pretty unique as it's a merge of OpenTracing and OpenCencus and has a lot of industry traction. When using the Java SDK you can include exporters to: * OTLP protocol, that can be sent to a collector (external process) that will run as an in-between to popular open-source and commercial distributed tracing products. * Maybe the java-instrumentation can be used for the TraveralOpProcessor, by doing the weaving through a javaagent? Don't know enough about TinkerPop if the above makes sense. > Allow registration of listeners for traversal iteration begin/end events > > > Key: TINKERPOP-2523 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2523 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.4.10 >Reporter: Clément de Groc >Priority: Minor > > In order to improve observability/monitoring (e.g. distributed tracing, > logging of traversals requests), it would be nice if users could register > custom listeners for traversal iteration begin/end events. > Those begin/end events are actually already nicely exposed as protected > methods in > [TraversalOpProcessor|https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L262-L272]. > Though, in 3.4.10, it is difficult to subclass TraversalOpProcessor to > override those methods as the > [OpLoader|https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/OpLoader.java#L47] > ensures only one OpProcessor can be loaded with name "traversal". > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2520) Add the ability to reverse the stream or a collection
[ https://issues.apache.org/jira/browse/TINKERPOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281883#comment-17281883 ] Stephen Mallette commented on TINKERPOP-2520: - Been thinking about this one a bit. I think we should simply disallow things like: {code} g.V().order().by('name').by(reverse) g.V().order().by(reverse).by('name') g.V().order().by(reverse).by(shuffle) {code} You can simply: {code} g.V().order().by(reverse) {code} We have similar rules around {{shuffle}} already but they don't explicitly result in error - the {{shuffle}} steps in between comparators are just removed and the mode of the order only goes to {{shuffle}} if that is the last {{Comparator}}. This would not prevent: {code} // g.V().order().by('name',desc) g.V(). order().by('name'). order().by(reverse) {code} I think that rather that doing magic with {{shuffle}} (and trying to do the same with {{reverse}}) perhaps we just require Gremlin to be formed where multiple {{Comparator}} instances can't be present where {{shuffle}} and {{reverse}} are in play. > Add the ability to reverse the stream or a collection > - > > Key: TINKERPOP-2520 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2520 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.4.10 >Reporter: Kelvin R. Lawrence >Priority: Minor > > I had a Gremlin user ask me yesterday if there was a way to have the results > of a `path` step be reversed. Today you cannot do that using `from` and `to` > steps as the `from` label must appear before the `to` label in a path. In > thinking about this, perhaps adding a `reverse` option to order (on top of > `asc`,`desc` and `shuffle`) would be a nice addition to Gremlin. So you could > write something like: > {code:java} > g.V().out().out().path().order(local).by(reverse){code} > For this specific user they were union-ing a set of paths in different > directions and wanted to normalize them to all be in the same direction when > presented as results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Adding motif support to match()
Thanks for the great feedback. In general, it seems like there is a lot of positive feedback on this idea and that it should be a separate from the existing match() step. I think there is one detail of my initial proposal that should probably be clarified. In my initial proposal I wasn't thinking about adding the entirety of openCypher/Cypher syntax to Gremlin. Instead, I was just thinking of adding the ASCII art portion of it. If we only go with ASCII art portion, then I would be hesitant to use the cypher() step as that would potentially imply more functionality than available. It seems like there are a few questions we need to decide: * Do we want to support more than just ASCII Art from cypher/openCypher? * For the ASCII art do we want to take more of the approach of cypher/openCypher or the graphX approach to adding filtering: Examples (ignore the step name it's a placeholder) Question: Find me all Companies within one hop of a Person vertex with a name of Dave with an employed_at edge openCypher/Cypher syntax: g.V().hasPattern("(p:Person {name: 'Dave'})-[e:employed_at]->(c:Company)") GraphX style syntax: g.V().hasPattern("(p)-[e]->(c)", __.as('p').has('Person', 'name', 'Dave'), __.as('e').hasLabel('employed_at'), __.as('c').hasLabel('Company'), ) Thoughts on these questions? Dave On Fri, Feb 5, 2021 at 4:36 AM Josh Perryman wrote: > I do like the approach of formally including openCypher / ASCII art into > Gremlin / TinkerPop. I'm reluctant to overload the match() step for that > purpose. > > The match() step does have a similar purpose, but it has a fraught history. > I think it would work better from a number of angles to leave it as it is. > > I'm more aligned with Joshua's recommendation. The use of the cypher() > step (or perhaps an openCypher() step?) makes explicit the transition to > another language and processing approach. This pairs nicely with the > sparql() step and provides an intuitive pattern to introduce other data > querying approaches ( sql(), gql(), prolog(), mmADT(), pigeon(), ... ). > > I do rather like the idea of the overloads within the step, ways to "hook" > the Gremlin into whatever the query language is. That could provide > remarkable flexibility and opens up a whole suite of capabilities. > > Overall, this is a really great idea which should help with > interoperability between TinkerPop and other graph frameworks. > > Josh > > > On Thu, Feb 4, 2021 at 10:30 PM pieter gmail > wrote: > > > +1 > > > > Cheers > > Pieter > > > > On Thu, 2021-02-04 at 17:15 -0800, Joshua Shinavier wrote: > > > Initial thought: if the ASCII art syntax is Cypher-like, why not make > > > it > > > openCypher proper? I.e. keep match() as it is, but generalize the > > > cypher() > > > step out of Neo4jGraph, with native Neo4j evaluation of Cypher as an > > > optimization. > > > > > > Josh > > > > > > > > > On Thu, Feb 4, 2021 at 2:17 PM David Bechberger > > > wrote: > > > > > > > Over the years of working with Gremlin I have foudn the match() > > > > step is > > > > difficult to create traversals with and even more difficult to make > > > > it work > > > > efficently. While the imperative style of programming in Gremlin > > > > provides > > > > a powerful path finding mechanism it really lacks an easy way to > > > > perform > > > > pattern matching queries. It would be great if we could simplify > > > > the > > > > match() step to enable users to easily generate these pattern > > > > matching > > > > traversals. > > > > > > > > To accomplish this I was wondering what adding support for a subset > > > > of > > > > motif/ascii art patterns to the match step might look like. These > > > > types of > > > > patterns are very easy for people to understand and I think the > > > > ability to > > > > combine these pattern matching syntax with the powerful path > > > > finding and > > > > formatting features of Gremlin would make a powerful combination. > > > > > > > > To accomplish this I am suggesting supporting a subset of potential > > > > patterns. The two most common examples of this sort of pattern out > > > > there > > > > are the openCypher type style and the style used by GraphX. I have > > > > provided a few examples below of what this syntax might look like: > > > > > > > > e.g. openCypher style > > > > > > > > Find me everything within one hop > > > > g.V().match("()-[]->()") > > > > > > > > Find me everything within one hop of a Person vertex > > > > g.V().match("(p:Person)-[]->()") > > > > > > > > Find me all Companies within one hop of a Person vertex > > > > g.V().match("(p:Person)-[]->(c:Company)") > > > > > > > > Find me all Companies within one hop of a Person vertex with an > > > > Employed_at > > > > edge > > > > g.V().match("(p:Person)-[e:employed_at]->(c:Company)") > > > > > > > > > > > > The other option would be to take more of a hybrid approach and use > > > > only > > > > the basic art/motifs like GraphX and apply the additional filtering > > > > in a > >
[jira] [Updated] (TINKERPOP-2520) Add the ability to reverse the stream or a collection
[ https://issues.apache.org/jira/browse/TINKERPOP-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette updated TINKERPOP-2520: Labels: breaking (was: ) I guess this is "breaking" as {{g.V().order().by('name').by(shuffle)}} would throw an exception on construction. > Add the ability to reverse the stream or a collection > - > > Key: TINKERPOP-2520 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2520 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.4.10 >Reporter: Kelvin R. Lawrence >Priority: Minor > Labels: breaking > > I had a Gremlin user ask me yesterday if there was a way to have the results > of a `path` step be reversed. Today you cannot do that using `from` and `to` > steps as the `from` label must appear before the `to` label in a path. In > thinking about this, perhaps adding a `reverse` option to order (on top of > `asc`,`desc` and `shuffle`) would be a nice addition to Gremlin. So you could > write something like: > {code:java} > g.V().out().out().path().order(local).by(reverse){code} > For this specific user they were union-ing a set of paths in different > directions and wanted to normalize them to all be in the same direction when > presented as results. -- This message was sent by Atlassian Jira (v8.3.4#803005)