[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)
