[jira] [Commented] (TINKERPOP-1599) implement real gremlin-python driver
[
https://issues.apache.org/jira/browse/TINKERPOP-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886537#comment-15886537
]
ASF GitHub Bot commented on TINKERPOP-1599:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/554
VOTE +1.
> implement real gremlin-python driver
>
>
> Key: TINKERPOP-1599
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1599
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, language-variant
>Affects Versions: 3.2.3
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.3.0
>
>
> It is high time that gremlin-python comes packaged with a real driver. After
> watching the community discussion, it seems that the way to go will be to use
> the {{concurrent.futures}} module with multithreading to provide asynchronous
> I/O. While the default underlying websocket client library will remain
> Tornado due to Python 2/3 compatibility issues, this should be decoupled from
> the rest of the client and easy to replace.
> With this is mind, I created a baseline client implementation with [this
> commit|https://github.com/apache/tinkerpop/commit/fb7e7f255585956abbb854fcc5dd3138113cf454]
> in a topic branch {{python_driver}}. Some things to note:
> - All I/O is performed using the {{concurrent.futures}} module, which
> provides a standard 2/3 compatible future interface.
> - The implementation currently does not include the concept of a cluster,
> instead it assumes a single host.
> - The {{transport}} interface makes it easy to plug in client libraries by
> defining a simple wrapper.
> - Because this is an example, I didn't fix all the tests to work with the new
> client implementation. Instead I just added a few demo tests. If we decide to
> move forward with this I will update the original tests.
> The resulting API looks like this for a simple client:
> {code}
> client = Client('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal()
> t = g.V()
> future_result_set = client.submitAsync(t.bytecode)
> result_set = future_result_set.result()
> results = result_set.all().result()
> client.close()
> {code}
> Using the {{DriverRemoteConnection}}:
> {code}
> conn = DriverRemoteConnection('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal().withRemote(conn)
> t = g.V()
> results = t.toList()
> conn.close()
> {code}
> If you have a minute to check out the new driver code that would be great, I
> welcome feedback and suggestions. If we decide to move forward like this, I
> will proceed to finish the driver implementation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #554: TINKERPOP-1599 implement real gremlin-python driver
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/554 VOTE +1. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.
[
https://issues.apache.org/jira/browse/TINKERPOP-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez closed TINKERPOP-1554.
-
Resolution: Won't Fix
This is a more complicated problem than I original assumed given how much logic
is based on {{PropertiesStep}} that will require {{HasPropertyStep}}
introspection.
> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
> private String propertyKey;
> public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.
[
https://issues.apache.org/jira/browse/TINKERPOP-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886370#comment-15886370
]
ASF GitHub Bot commented on TINKERPOP-1554:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/560
Realizing that this should really go into `master/` as I just walked
through a bunch of the code and notes that we use `PropertiesStep` a lot
through out various traversal strategies. Going to change my VOTE to -1 as this
problem is more complicated that I originally assumed.
> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
> private String propertyKey;
> public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #560: TINKERPOP-1554: has(propertyKey) should have a corresp...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/560 Realizing that this should really go into `master/` as I just walked through a bunch of the code and notes that we use `PropertiesStep` a lot through out various traversal strategies. Going to change my VOTE to -1 as this problem is more complicated that I originally assumed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #560: TINKERPOP-1554: has(propertyKey) should have a ...
Github user okram closed the pull request at: https://github.com/apache/tinkerpop/pull/560 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.
[
https://issues.apache.org/jira/browse/TINKERPOP-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886371#comment-15886371
]
ASF GitHub Bot commented on TINKERPOP-1554:
---
Github user okram closed the pull request at:
https://github.com/apache/tinkerpop/pull/560
> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
> private String propertyKey;
> public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #560: TINKERPOP-1554: has(propertyKey) should have a corresp...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/560 VOTE: +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.
[
https://issues.apache.org/jira/browse/TINKERPOP-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886296#comment-15886296
]
ASF GitHub Bot commented on TINKERPOP-1554:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/560
VOTE: +1
> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
> private String propertyKey;
> public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (TINKERPOP-1528) CountByIsRangeStrategy fails for a particular query
[
https://issues.apache.org/jira/browse/TINKERPOP-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1528.
-
Resolution: Fixed
Fix Version/s: 3.2.5
3.3.0
Fixed by https://github.com/apache/tinkerpop/pull/563
> CountByIsRangeStrategy fails for a particular query
> ---
>
> Key: TINKERPOP-1528
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1528
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> In a fresh TinkerGraph:
> {noformat}
> gremlin> g.V().count()
> ==>0
> gremlin> g.V().count().is(0)
> gremlin>
> {noformat}
> Because of {{.is(0)}} the traversal is converted to something like
> {{g.not(V())}}. No issues with other values (!= 0).
> {noformat}
> gremlin> g.addV()
> ==>v[0]
> gremlin> g.V().count()
> ==>1
> gremlin> g.V().count().is(0)
> gremlin> g.V().count().is(1)
> ==>1
> gremlin> g.V().count().is(2)
> gremlin>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (TINKERPOP-1638) count() is optimized away in where()
[
https://issues.apache.org/jira/browse/TINKERPOP-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1638.
-
Resolution: Fixed
Fix Version/s: 3.2.5
3.3.0
> count() is optimized away in where()
>
>
> Key: TINKERPOP-1638
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1638
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> See also [gremlin-users
> discussion|https://groups.google.com/d/msg/gremlin-users/GCh2M9PVd7g/iLZE4L9wBgAJ]
> This produces no results:
> {noformat}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) )
> gremlin>
> {noformat}
> In 3.2.0-incubating, it correctly (or atleast expectedly) produces:
> {noformat}
> ==>v[1]
> ==>v[2]
> ==>v[3]
> ==>v[4]
> ==>v[5]
> ==>v[6]
> {noformat}
> Outside of the where() clause, it produces the expected result:
> {noformat}
> gremlin> g.V().in('A').in('B').count()
> ==>0
> {noformat}
> Thus, one could expect it to work inside the where() clause. It appears that
> some optimization occurs that removes the count step and converts it into a
> NotStep.
> 3.2.0-incubating:
> {noformat}
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) ).explain()
> ==>Traversal Explanation
>
> Original Traversal [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> IdentityRemovalStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> FilterRankingStrategy[O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> MatchPredicateStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> RangeByIsCountStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> ProfileStrategy [F] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> Final Traversal[TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> {noformat}
> 3.2.4:
> {noformat}
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) ).explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> MatchPredicateStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> FilterRankingStr
[jira] [Commented] (TINKERPOP-1638) count() is optimized away in where()
[
https://issues.apache.org/jira/browse/TINKERPOP-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886289#comment-15886289
]
ASF GitHub Bot commented on TINKERPOP-1638:
---
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/563
> count() is optimized away in where()
>
>
> Key: TINKERPOP-1638
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1638
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>
> See also [gremlin-users
> discussion|https://groups.google.com/d/msg/gremlin-users/GCh2M9PVd7g/iLZE4L9wBgAJ]
> This produces no results:
> {noformat}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) )
> gremlin>
> {noformat}
> In 3.2.0-incubating, it correctly (or atleast expectedly) produces:
> {noformat}
> ==>v[1]
> ==>v[2]
> ==>v[3]
> ==>v[4]
> ==>v[5]
> ==>v[6]
> {noformat}
> Outside of the where() clause, it produces the expected result:
> {noformat}
> gremlin> g.V().in('A').in('B').count()
> ==>0
> {noformat}
> Thus, one could expect it to work inside the where() clause. It appears that
> some optimization occurs that removes the count step and converts it into a
> NotStep.
> 3.2.0-incubating:
> {noformat}
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) ).explain()
> ==>Traversal Explanation
>
> Original Traversal [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> IdentityRemovalStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> FilterRankingStrategy[O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> MatchPredicateStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> RangeByIsCountStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> ProfileStrategy [F] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> Final Traversal[TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> {noformat}
> 3.2.4:
> {noformat}
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) ).explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> MatchPredicateStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGl
[GitHub] tinkerpop pull request #563: TINKERPOP-1638 count() is optimized away in whe...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/563 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1599) implement real gremlin-python driver
[
https://issues.apache.org/jira/browse/TINKERPOP-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886093#comment-15886093
]
ASF GitHub Bot commented on TINKERPOP-1599:
---
Github user davebshow commented on the issue:
https://github.com/apache/tinkerpop/pull/554
I think this is ready. Anyone want to be a third reviewer for this?
VOTE +1
> implement real gremlin-python driver
>
>
> Key: TINKERPOP-1599
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1599
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, language-variant
>Affects Versions: 3.2.3
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.3.0
>
>
> It is high time that gremlin-python comes packaged with a real driver. After
> watching the community discussion, it seems that the way to go will be to use
> the {{concurrent.futures}} module with multithreading to provide asynchronous
> I/O. While the default underlying websocket client library will remain
> Tornado due to Python 2/3 compatibility issues, this should be decoupled from
> the rest of the client and easy to replace.
> With this is mind, I created a baseline client implementation with [this
> commit|https://github.com/apache/tinkerpop/commit/fb7e7f255585956abbb854fcc5dd3138113cf454]
> in a topic branch {{python_driver}}. Some things to note:
> - All I/O is performed using the {{concurrent.futures}} module, which
> provides a standard 2/3 compatible future interface.
> - The implementation currently does not include the concept of a cluster,
> instead it assumes a single host.
> - The {{transport}} interface makes it easy to plug in client libraries by
> defining a simple wrapper.
> - Because this is an example, I didn't fix all the tests to work with the new
> client implementation. Instead I just added a few demo tests. If we decide to
> move forward with this I will update the original tests.
> The resulting API looks like this for a simple client:
> {code}
> client = Client('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal()
> t = g.V()
> future_result_set = client.submitAsync(t.bytecode)
> result_set = future_result_set.result()
> results = result_set.all().result()
> client.close()
> {code}
> Using the {{DriverRemoteConnection}}:
> {code}
> conn = DriverRemoteConnection('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal().withRemote(conn)
> t = g.V()
> results = t.toList()
> conn.close()
> {code}
> If you have a minute to check out the new driver code that would be great, I
> welcome feedback and suggestions. If we decide to move forward like this, I
> will proceed to finish the driver implementation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #554: TINKERPOP-1599 implement real gremlin-python driver
Github user davebshow commented on the issue: https://github.com/apache/tinkerpop/pull/554 I think this is ready. Anyone want to be a third reviewer for this? VOTE +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1641) Authentication for gremlin-python
[ https://issues.apache.org/jira/browse/TINKERPOP-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886063#comment-15886063 ] Marc de Lignie commented on TINKERPOP-1641: --- To get debug info from gremlin server during gremlin-python authentication development: * run standalone bin/gremlin-server.sh 3.3.0-SNAPSHOT (branch master) with: ** new conf/gremlin-server-testpython.yaml (port 45942, SimpleAuthenticator or Krb5Authenticator) ** DEBUG in conf/log4j.properties file * adapt conftest.py to use port 45942 in PR554 * mvn clean install -DskipTests * mvn install -pl gremlin-python -Pglv-python > Authentication for gremlin-python > - > > Key: TINKERPOP-1641 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1641 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.3.0 >Reporter: Marc de Lignie >Priority: Minor > > Follow-up on > [TINKERPOP-1566|https://issues.apache.org/jira/browse/TINKERPOP-1566]: > * make gremlin-python authenticate against SimpleAuthenticator and > Krb5Authenticator > * add audit logging for bytecode requests (in addition to existing audit > logging of scrip requests and of the authenticated user by TINKERPOP-1566) > * tests and documentation for this -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1638) count() is optimized away in where()
[
https://issues.apache.org/jira/browse/TINKERPOP-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885823#comment-15885823
]
ASF GitHub Bot commented on TINKERPOP-1638:
---
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/563
VOTE +1
> count() is optimized away in where()
>
>
> Key: TINKERPOP-1638
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1638
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.1
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
>
> See also [gremlin-users
> discussion|https://groups.google.com/d/msg/gremlin-users/GCh2M9PVd7g/iLZE4L9wBgAJ]
> This produces no results:
> {noformat}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) )
> gremlin>
> {noformat}
> In 3.2.0-incubating, it correctly (or atleast expectedly) produces:
> {noformat}
> ==>v[1]
> ==>v[2]
> ==>v[3]
> ==>v[4]
> ==>v[5]
> ==>v[6]
> {noformat}
> Outside of the where() clause, it produces the expected result:
> {noformat}
> gremlin> g.V().in('A').in('B').count()
> ==>0
> {noformat}
> Thus, one could expect it to work inside the where() clause. It appears that
> some optimization occurs that removes the count step and converts it into a
> NotStep.
> 3.2.0-incubating:
> {noformat}
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) ).explain()
> ==>Traversal Explanation
>
> Original Traversal [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> IdentityRemovalStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> FilterRankingStrategy[O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> MatchPredicateStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> CountGlobalStep, IsStep(eq(0))])]
> RangeByIsCountStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> ProfileStrategy [F] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> Final Traversal[TinkerGraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],edge),
> RangeGlobalStep(0,1), CountGlobalStep, IsStep(eq(0))])]
> {noformat}
> 3.2.4:
> {noformat}
> gremlin> g.V().where( __.in('A').in('B').count().is(eq(0)) ).explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vertex),
> CountGlobalStep, IsStep(eq(0))])]
> MatchPredicateStrategy [O] [GraphStep(vertex,[]),
> TraversalFilterStep([VertexStep(IN,[A],vertex), VertexStep(IN,[B],vert
[GitHub] tinkerpop issue #563: TINKERPOP-1638 count() is optimized away in where()
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/563 VOTE +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.
[
https://issues.apache.org/jira/browse/TINKERPOP-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885816#comment-15885816
]
ASF GitHub Bot commented on TINKERPOP-1554:
---
Github user okram commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/560#discussion_r103210119
--- Diff:
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/FilterRankingStrategyTest.java
---
@@ -106,7 +106,7 @@ public void doTest() {
{__.dedup().has("value", 0).or(not(has("age")), has("age",
10)).has("value", 1), __.has("value", 0).has("value", 1).or(not(has("age")),
has("age", 10)).dedup(),
Collections.singletonList(InlineFilterStrategy.instance())},
{__.dedup().filter(out()).has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
{filter(out()).dedup().has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
-{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().where(P.eq("a")).has("age"), Collections.emptyList()},
+{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().has("age").where(P.eq("a")), Collections.emptyList()},
--- End diff --
`where(eq('a')` might be faster, but probably not. But we don't know what
the `P` predicate is. If its something more complex, than `==` then it will be
slower. And no, `ReferenceVertex` doesn't come into play here as those are
resolved at "attachment" and not dynamically in mid-traversal.
> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
> private String propertyKey;
> public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop pull request #560: TINKERPOP-1554: has(propertyKey) should have a ...
Github user okram commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/560#discussion_r103210119
--- Diff:
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/FilterRankingStrategyTest.java
---
@@ -106,7 +106,7 @@ public void doTest() {
{__.dedup().has("value", 0).or(not(has("age")), has("age",
10)).has("value", 1), __.has("value", 0).has("value", 1).or(not(has("age")),
has("age", 10)).dedup(),
Collections.singletonList(InlineFilterStrategy.instance())},
{__.dedup().filter(out()).has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
{filter(out()).dedup().has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
-{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().where(P.eq("a")).has("age"), Collections.emptyList()},
+{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().has("age").where(P.eq("a")), Collections.emptyList()},
--- End diff --
`where(eq('a')` might be faster, but probably not. But we don't know what
the `P` predicate is. If its something more complex, than `==` then it will be
slower. And no, `ReferenceVertex` doesn't come into play here as those are
resolved at "attachment" and not dynamically in mid-traversal.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Closed] (TINKERPOP-1566) Kerberos authentication for gremlin-server
[ https://issues.apache.org/jira/browse/TINKERPOP-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1566. --- Resolution: Done Assignee: stephen mallette > Kerberos authentication for gremlin-server > -- > > Key: TINKERPOP-1566 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1566 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Marc de Lignie >Assignee: stephen mallette >Priority: Minor > Labels: security > Fix For: 3.3.0 > > > Gremlin server would benefit from an explicit Kerberos authentication plugin, > because preparing and maintaining such a plugin is nontrivial. Also, many > other Apache project provide kerberized services. > In gremlin-console the standard Krb5LoginModule can be configured. > Gremlin-server already includes the pluggable Sasl framework that can host > the proposed Kerberos authentication plugin. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server
[ https://issues.apache.org/jira/browse/TINKERPOP-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885656#comment-15885656 ] ASF GitHub Bot commented on TINKERPOP-1566: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/534 > Kerberos authentication for gremlin-server > -- > > Key: TINKERPOP-1566 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1566 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Marc de Lignie >Priority: Minor > Labels: security > Fix For: 3.3.0 > > > Gremlin server would benefit from an explicit Kerberos authentication plugin, > because preparing and maintaining such a plugin is nontrivial. Also, many > other Apache project provide kerberized services. > In gremlin-console the standard Krb5LoginModule can be configured. > Gremlin-server already includes the pluggable Sasl framework that can host > the proposed Kerberos authentication plugin. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] tinkerpop pull request #534: TINKERPOP-1566 Kerberos authentication for grem...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/534 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #560: TINKERPOP-1554: has(propertyKey) should have a ...
Github user dkuppitz commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/560#discussion_r103189226
--- Diff:
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/FilterRankingStrategyTest.java
---
@@ -106,7 +106,7 @@ public void doTest() {
{__.dedup().has("value", 0).or(not(has("age")), has("age",
10)).has("value", 1), __.has("value", 0).has("value", 1).or(not(has("age")),
has("age", 10)).dedup(),
Collections.singletonList(InlineFilterStrategy.instance())},
{__.dedup().filter(out()).has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
{filter(out()).dedup().has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
-{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().where(P.eq("a")).has("age"), Collections.emptyList()},
+{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().has("age").where(P.eq("a")), Collections.emptyList()},
--- End diff --
Should `has("age")` really be processed prior `where(eq("a"))`? I would
assume that the latter is generally faster (and significantly faster if you're
dealing with a `ReferenceVertex` that - afaik - fetches properties only on
request).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.
[
https://issues.apache.org/jira/browse/TINKERPOP-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885630#comment-15885630
]
ASF GitHub Bot commented on TINKERPOP-1554:
---
Github user dkuppitz commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/560#discussion_r103189226
--- Diff:
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/FilterRankingStrategyTest.java
---
@@ -106,7 +106,7 @@ public void doTest() {
{__.dedup().has("value", 0).or(not(has("age")), has("age",
10)).has("value", 1), __.has("value", 0).has("value", 1).or(not(has("age")),
has("age", 10)).dedup(),
Collections.singletonList(InlineFilterStrategy.instance())},
{__.dedup().filter(out()).has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
{filter(out()).dedup().has("value", 0), has("value",
0).filter(out()).dedup(), Collections.emptyList()},
-{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().where(P.eq("a")).has("age"), Collections.emptyList()},
+{__.as("a").out().has("age").where(P.eq("a")),
__.as("a").out().has("age").where(P.eq("a")), Collections.emptyList()},
--- End diff --
Should `has("age")` really be processed prior `where(eq("a"))`? I would
assume that the latter is generally faster (and significantly faster if you're
dealing with a `ReferenceVertex` that - afaik - fetches properties only on
request).
> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
> private String propertyKey;
> public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
