[jira] [Closed] (TINKERPOP-1956) Deprecate Order incr/decr for asc/desc
[
https://issues.apache.org/jira/browse/TINKERPOP-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1956.
---
Resolution: Done
Fix Version/s: 3.3.4
I guess i'll leave this on 3.3.4 since we'll remove the deprecation on 3.4.0?
> Deprecate Order incr/decr for asc/desc
> --
>
> Key: TINKERPOP-1956
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1956
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Labels: deprecation
> Fix For: 3.3.4
>
>
> {{Order}} uses {{incr}} and {{decr}} which aren't terribly standard sounding
> names for query languages where folks are more used to seeing {{asc}} and
> {{desc}}. Deprecate the old terms in favor of these new ones. Since {{incr}}
> and {{decr}} are in wide usage now, we might not be in a rush to remove them
> completely any time soon - but that's a separate discussion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1956) Deprecate Order incr/decr for asc/desc
[
https://issues.apache.org/jira/browse/TINKERPOP-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479662#comment-16479662
]
ASF GitHub Bot commented on TINKERPOP-1956:
---
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/861
> Deprecate Order incr/decr for asc/desc
> --
>
> Key: TINKERPOP-1956
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1956
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Labels: deprecation
>
> {{Order}} uses {{incr}} and {{decr}} which aren't terribly standard sounding
> names for query languages where folks are more used to seeing {{asc}} and
> {{desc}}. Deprecate the old terms in favor of these new ones. Since {{incr}}
> and {{decr}} are in wide usage now, we might not be in a rush to remove them
> completely any time soon - but that's a separate discussion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #861: TINKERPOP-1956 Deprecated Order.incr and Order....
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/861 ---
[jira] [Commented] (TINKERPOP-1956) Deprecate Order incr/decr for asc/desc
[
https://issues.apache.org/jira/browse/TINKERPOP-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479625#comment-16479625
]
ASF GitHub Bot commented on TINKERPOP-1956:
---
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/861
VOTE +1
> Deprecate Order incr/decr for asc/desc
> --
>
> Key: TINKERPOP-1956
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1956
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Labels: deprecation
>
> {{Order}} uses {{incr}} and {{decr}} which aren't terribly standard sounding
> names for query languages where folks are more used to seeing {{asc}} and
> {{desc}}. Deprecate the old terms in favor of these new ones. Since {{incr}}
> and {{decr}} are in wide usage now, we might not be in a rush to remove them
> completely any time soon - but that's a separate discussion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #861: TINKERPOP-1956 Deprecated Order.incr and Order.decr
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/861 VOTE +1 ---
[DISCUSS] with() modulator
We currently have nice ways to provide configurations to a TraversalSource
using variations of "with" like
withStrategies()
withSideEffects()
I think it would be equally nice to provide configurations to individual
steps. So, what would we use this for? Well, one thing I really dislike is
our use of by() for configuring parameters to steps like pageRank() and
peerPressure():
g.V().pageRank().by('rank')
That by('rank') sets the property name that will be used to store the
pagerank value on the vertex. Not only is that a little awkward, but it
also only allows for one configuration, so if we wanted to set some other
values on pageRank() we couldn't really do it (unless the argument happens
to match one of the other by() overloads - which is what are lucky about
doing now). If we had the with() modulator, then we could do:
g.V().pageRank().with(PageRankVertexProgram.PROPERTY,'rank')
Arguably longer, but with appropriate overloads and helpers that could be
instead:
g.V().pageRank().with(pageRankKey('rank'))
or something similar - certainly more descriptive than by('rank') which
really doesn't match our common uses of by() with other steps.
The with() modulator would also provide a fair amount of flexibility to any
provider looking for a first class way for users to send configurations on
steps that might yield control over conditions/logic in custom step
replacements.
Unless there objections in the next 72 hours (Sunday, May 20, 2018, 3:30pm)
to this direction, I'll get a JIRA ticket created and look to have this for
3.4.0.
Take care,
Stephen
Re: [DISCUSS] Depth First Repeat step
I got a bit busy for a few weeks and didn't' really have much time to focus on in on this thread. I figured I'd let it off my mind for a while and see if any new thoughts came up on it. Coming back on it now, I still think I like the approach I summarized from my own thoughts and others on the thread, but let me try to address a few things that were posted since my last reply: >From pieter's last reply: > What bothers me with this is that its in the negative. Providers now have too look for a specific strategy NOT being present to alter the behavior of the traversal. I suppose sqlg has gone down a path where the general strategies of TinkerPop don't always equate to the best way to do things. Do any other graph providers run into such an issue? I don't necessarily ask that question of Pieter, but of any graph providers out there who are following along. I'm personally not aware of any, but I'd be curious to know if there were others. > Another thought about if we go with the `.withoutStrategies(Lazy...)`. Should these semantic marker type strategies not then be interfaces rather than concrete implementations. that might be true. we'd need to look at that more carefully in the implementation to see what makes sense. maybe we just need a marker interface for such strategies? >From Keith's last reply: > my main concern is there’s not really any great documentation around what LazyBarrierStrategy really does. true - we will want to write more about this for sure if it's to control the traversal algorithm. On Tue, May 1, 2018 at 9:53 AM, Keith Lohnes wrote: > I presume that would be some source of technical derailment to this > approach > > Not necessarily, just the “step to define traversal order” idea. The > RepeatStep, at least from what I’ve seen, seems simplest to implement as a > BFS. BFS is easily made depth first with a stack. I think that can still be > the case with the RepeatStep here, it would just need another means of > determining which algorithm to use. That could probably be “Does this > repeat traversal end with a barrier step?” If that seems reasonable for > RepeatSteps then maybe that could help with some of Pieter’s “check for a > negative” concerns. > > Full BFS: manually add barrier()‘s > > Mixed mode: Default, let strategies do their thing OR remove strategies and > manually add your own barrier() > Full DFS: execute .withoutStrategies(Lazy...) > > This sounds reasonable, but my main concern is there’s not really any great > documentation around what LazyBarrierStrategy really does. Sure, you can > read the code, but I think that as the documentation currently sits, > inserts > barrier()-steps into a traversal where appropriate in order to gain the > "bulking optimization." is a bit vague. “Where appropriate” should probably > be well defined in the documentation so users can have a good understanding > of when that is without having to go to the code. > > On Sun, Apr 29, 2018 at 6:17 AM pieter gmail > wrote: > > So to clarify, you write, > > > > Full DFS: execute `.withoutStrategies(Lazy...)` > > > > What bothers me with this is that its in the negative. Providers now > > have too look for a specific strategy NOT being present to alter the > > behavior of the traversal. > > > > SubgraphStrategy and EventStrategy and all others that I am aware of are > > positive. They do what they do and then the provider goes about its > > business optimizing the steps that are present. In the negative its more > > like a directive to the provider about the semantics of the traversal's > > steps. > > > > Another thought about if we go with the `.withoutStrategies(Lazy...)`. > > Should these semantic marker type strategies not then be interfaces > > rather than concrete implementations. Specifically with respect my vague > > understanding of whats coming with version 4, where the gremlin > > specification is completely detached from TinkerPop's reference > > implementation and perhaps even the JDK itself. > > > > Cheers > > Pieter > > > > On 29/04/2018 00:38, Stephen Mallette wrote: > > >> Is the objection to order(SearchAlgo) that it overloads order() or > an > > > objection to specifying, DFS/BFS in the traversal itself? > > > > > > for me, order() is a step. not a modulator. making it work as presented > > in > > > the pull request conflates those two concepts which i think is > confusing > > (i > > > don't think we do that anywhere else, but feel free to correct me if > i'm > > > wrong). > > > > > >> As mentioned earlier I am not a fan of making the user deal with > > > strategies. Strategies to my mind is not part of the gremlin as a > > language > > > specification > > > > > > There are already precedents for users dealing with strategies. > Consider > > > the decorations like SubgraphStrategy, EventStrategy, etc. So, it is > not > > > foreign or hidden. It is a component of traversal configuration. > > > > > > I would have to think about a new step like traverse(). I'd prefer
[jira] [Commented] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients
[ https://issues.apache.org/jira/browse/TINKERPOP-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479582#comment-16479582 ] Ashwini Singh commented on TINKERPOP-1913: -- Hi I am not an expert on javascript and python. Can owners of python and javascript take this up. Thanks Ashwini > Expose metadata from Gremlin Server to Clients > -- > > Key: TINKERPOP-1913 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1913 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, driver, javascript, python, server >Affects Versions: 3.3.1 >Reporter: Ashwini Singh >Assignee: stephen mallette >Priority: Major > > To summarize what we have discussed so far: > 1. For API using GremlinRequest/QueryScript, expose response attribute as > part of result. Using an approach to similar to Java client driver (using > ResultSet) . [Priority0] > -- We rely on the last message for response attributes. > 2. For GLV, add response attribute as part of Traversal. [Priority 0] > --Rely on the last message for attributes. > 3. Expose other server details (like server setting). I would suggest to > split this design discussion into two directions: > a. Metadata for request execution: Only focuses on details > related to request execution. Can be achieved through #1 and #2. > b. Metadata for Gremlin Server: Focuses on overall metadata > for the server. Could be a separate request and fetch the data once for a > connection. > Targeted drivers: dotnet, Java, python, javascript. > More details: > [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-1852) Recipe fails for highly meshed connected components
[ https://issues.apache.org/jira/browse/TINKERPOP-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479477#comment-16479477 ] stephen mallette edited comment on TINKERPOP-1852 at 5/17/18 6:05 PM: -- Closing this in favor of TINKERPOP-1967 - probably better to add something explicit to deal with this common requirement. was (Author: spmallette): Closing this in favor of TINKERPOP-1852 - probably better to add something explicit to deal with this common requirement. > Recipe fails for highly meshed connected components > --- > > Key: TINKERPOP-1852 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1852 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Affects Versions: 3.3.0, 3.2.6 > Environment: gremlin-console >Reporter: Marc de Lignie >Priority: Minor > > On the JanusGraph user list the connected-components recipe was shown to fail > for a completely meshed component with a size of 35. The successive thread > [https://groups.google.com/forum/#!topic/janusgraph-users/NmwZyag1w2M] shows > a better solution, both as a mixed groovy-gremlin and a pure gremlin query > (with the latter having slightly less well scaling behavior because of the > required path computations). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1852) Recipe fails for highly meshed connected components
[ https://issues.apache.org/jira/browse/TINKERPOP-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1852. --- Resolution: Won't Do > Recipe fails for highly meshed connected components > --- > > Key: TINKERPOP-1852 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1852 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Affects Versions: 3.3.0, 3.2.6 > Environment: gremlin-console >Reporter: Marc de Lignie >Priority: Minor > > On the JanusGraph user list the connected-components recipe was shown to fail > for a completely meshed component with a size of 35. The successive thread > [https://groups.google.com/forum/#!topic/janusgraph-users/NmwZyag1w2M] shows > a better solution, both as a mixed groovy-gremlin and a pure gremlin query > (with the latter having slightly less well scaling behavior because of the > required path computations). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1852) Recipe fails for highly meshed connected components
[ https://issues.apache.org/jira/browse/TINKERPOP-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1852. --- Resolution: Won't Do Closing this in favor of TINKERPOP-1852 - probably better to add something explicit to deal with this common requirement. > Recipe fails for highly meshed connected components > --- > > Key: TINKERPOP-1852 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1852 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Affects Versions: 3.3.0, 3.2.6 > Environment: gremlin-console >Reporter: Marc de Lignie >Priority: Minor > > On the JanusGraph user list the connected-components recipe was shown to fail > for a completely meshed component with a size of 35. The successive thread > [https://groups.google.com/forum/#!topic/janusgraph-users/NmwZyag1w2M] shows > a better solution, both as a mixed groovy-gremlin and a pure gremlin query > (with the latter having slightly less well scaling behavior because of the > required path computations). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (TINKERPOP-1852) Recipe fails for highly meshed connected components
[ https://issues.apache.org/jira/browse/TINKERPOP-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1852: - > Recipe fails for highly meshed connected components > --- > > Key: TINKERPOP-1852 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1852 > Project: TinkerPop > Issue Type: Bug > Components: documentation >Affects Versions: 3.3.0, 3.2.6 > Environment: gremlin-console >Reporter: Marc de Lignie >Priority: Minor > > On the JanusGraph user list the connected-components recipe was shown to fail > for a completely meshed component with a size of 35. The successive thread > [https://groups.google.com/forum/#!topic/janusgraph-users/NmwZyag1w2M] shows > a better solution, both as a mixed groovy-gremlin and a pure gremlin query > (with the latter having slightly less well scaling behavior because of the > required path computations). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-1967) Add a connectedComponent() step
stephen mallette created TINKERPOP-1967:
---
Summary: Add a connectedComponent() step
Key: TINKERPOP-1967
URL: https://issues.apache.org/jira/browse/TINKERPOP-1967
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.3.3
Reporter: stephen mallette
Assignee: stephen mallette
Fix For: 3.4.0
Given TINKERPOP-1852 we should probably just simplify and improve performance
of connected component identification. Implementing this will involved the
creation of {{ConnectedComponentVertexProgram}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1966) pageRank() and peerPressure() step should better respect halted traversers
stephen mallette created TINKERPOP-1966:
---
Summary: pageRank() and peerPressure() step should better respect
halted traversers
Key: TINKERPOP-1966
URL: https://issues.apache.org/jira/browse/TINKERPOP-1966
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.2.9
Reporter: stephen mallette
Assignee: stephen mallette
{{pageRank()}} and {{peerPressure()}} both fail to completely respect halted
traversers so that the results of queries that do this:
{code}
g.V().hasLabel('person').pageRank()
{code}
don't return the right result. In the above case, the initial rank assigned
respects halted traversers (i.e. those still part of the traversal after the
{{hasLabel()}} filter) but the future iterations do not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1965) Make MessageCombiner a bit more flexible
stephen mallette created TINKERPOP-1965:
---
Summary: Make MessageCombiner a bit more flexible
Key: TINKERPOP-1965
URL: https://issues.apache.org/jira/browse/TINKERPOP-1965
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.3.3
Reporter: stephen mallette
Assignee: stephen mallette
Fix For: 3.4.0
Currently {{MessageCombiner}} takes two messages and forces them to one, but in
some cases you might want to have logic that makes the choice as to whether or
not to combine or keep the messages separate. Perhaps the signature should be:
{code}
public List combine(final M messageA, final M messageB);
{code}
or something similar that would allow return of one object or two. Not sure if
it is worth deprecating the old code - perhaps we just make it a straight
breaking change on 3.4.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
