[jira] [Commented] (TINKERPOP-1468) GraphTraversal.optional throws a NPE if no traversal is provided

2016-10-26 Thread Robert Dale (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15610355#comment-15610355
 ] 

Robert Dale commented on TINKERPOP-1468:


I guess it depends on how user friendly you want to be Vs. accepting certain 
groovy-isms.

You could null check here and provide a friendly message like the ticket 
suggests.  Ideally that would be consistent everywhere. That could be a lot of 
places.  Is that work done all at once or case by case?

Even with that in place, there are certain groovy-isms that can't be avoided: 
```
gremlin> g.V().choose()
Could not find which method choose() to invoke from this list:
```
But maybe that message is user friendly enough.

I wonder what other GLVs do.

> GraphTraversal.optional throws a NPE if no traversal is provided
> 
>
> Key: TINKERPOP-1468
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1468
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Ted Wilmes
>  Labels: trivial
>
> {{GraphTraversal.optional}} throws a NPE if no traversal is provided.  We 
> should probably throw a friendlier exception with instructions to provide a 
> traversal as an argument.
> {code}
> gremlin> g.V().optional()
> java.lang.NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.lang.NullPointerException
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.optional(GraphTraversal.java:1316)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TINKERPOP-1485) Move source for TinkerPop site to source code repo

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15610246#comment-15610246
 ] 

ASF GitHub Bot commented on TINKERPOP-1485:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/459
  
I added @robertdale and the "Gremlin implementation of the Gremlin 
Traversal Machine" blog post and used both `generate-home.sh` and 
`publish-home.sh` and everything working as expected.

  http://tinkerpop.apache.org/

One nick nack -- if others agree -- I think the homepage should be in the 
docs directory. `docs/site`. and then `site/bin` scripts should just be in 
`bin/`. 

Regardless -- VOTE +1.


> Move source for TinkerPop site to source code repo
> --
>
> Key: TINKERPOP-1485
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1485
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0
>
>
> Some time ago there was discussion on the Mailing List to move the web site 
> to the source code repo so that it could be contributed to via pull request. 
> It would be nice because then we could better rely on some basic static site 
> generation to help deal with repetitive and sometimes error prone process of 
> updating the header for the pages.
> Anyway, a few thoughts:
> 1. need a shell script to publish the site to svn - something like 
> {{bin/publish-site.sh}}
> 2. place files in the root of the project in a directory called {{site/}}
> 3. if possible, do some basic site generation with maybe some groovy script 
> or just the shell script mentioned above to inject a "header file" for each 
> page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] tinkerpop issue #459: TINKERPOP-1485 Move source for TinkerPop site to sourc...

2016-10-26 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/459
  
I added @robertdale and the "Gremlin implementation of the Gremlin 
Traversal Machine" blog post and used both `generate-home.sh` and 
`publish-home.sh` and everything working as expected.

  http://tinkerpop.apache.org/

One nick nack -- if others agree -- I think the homepage should be in the 
docs directory. `docs/site`. and then `site/bin` scripts should just be in 
`bin/`. 

Regardless -- 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.
---


[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-26 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
@okram did you understand the nature of the comment @dalaro made about #466 
? 

All tests pass with `docker/build.sh -t -n -i`

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.
---


[GitHub] tinkerpop issue #458: Message scope initialization in PeerPressureVertexProg...

2016-10-26 Thread sjudeng
Github user sjudeng commented on the issue:

https://github.com/apache/tinkerpop/pull/458
  
Should be good now. I first tried to do this by reapplying the commit on 
tp32 before I realized I needed to edit the PR itself.


---
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 issue #458: Message scope initialization in PeerPressureVertexProg...

2016-10-26 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/458
  
@sjudeng do you mind re-targeting this pull request to the tp32 branch? In 
that way it will get fixed along the 3.2.x line of code. we can merge forward 
to master on our end so that is available on 3.3.x as well.


---
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.
---


Re: [DISCUSS] Add neo4j-gremlin-bolt to provider index

2016-10-26 Thread Stephen Mallette
yeah - they didn't meet our policy for listing on the provider page.

On Wed, Oct 26, 2016 at 3:57 PM, Robert Dale  wrote:

> Ok, I see it now. I was looking at 'providers'
> http://tinkerpop.apache.org/providers.html
>
> Robert Dale
>
> On Wed, Oct 26, 2016 at 3:53 PM, Stephen Mallette 
> wrote:
>
> > it's already on the home page
> >
> > https://github.com/SteelBridgeLabs/neo4j-gremlin-bolt
> >
> > On Wed, Oct 26, 2016 at 3:48 PM, Robert Dale  wrote:
> >
> > > Stephen, when this is added, could you send out the URL?  Thanks.
> > >
> > > On Thu, Oct 20, 2016 at 9:58 AM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > It looks like neo4j-gremlin-bolt meets our policy for adding it to
> our
> > > > provider index. I asked the maintainer if he'd like it added and the
> > > answer
> > > > was "yes". Unless there are objections in the next 72 hours (Sunday,
> > > > October 23, 2016 at 10am EST), I will assume lazy consensus and add
> it
> > to
> > > > the index.
> > > >
> > >
> > >
> > >
> > > --
> > > Robert Dale
> > >
> >
>


Re: [DISCUSS] Add neo4j-gremlin-bolt to provider index

2016-10-26 Thread Robert Dale
Ok, I see it now. I was looking at 'providers'
http://tinkerpop.apache.org/providers.html

Robert Dale

On Wed, Oct 26, 2016 at 3:53 PM, Stephen Mallette 
wrote:

> it's already on the home page
>
> https://github.com/SteelBridgeLabs/neo4j-gremlin-bolt
>
> On Wed, Oct 26, 2016 at 3:48 PM, Robert Dale  wrote:
>
> > Stephen, when this is added, could you send out the URL?  Thanks.
> >
> > On Thu, Oct 20, 2016 at 9:58 AM, Stephen Mallette 
> > wrote:
> >
> > > It looks like neo4j-gremlin-bolt meets our policy for adding it to our
> > > provider index. I asked the maintainer if he'd like it added and the
> > answer
> > > was "yes". Unless there are objections in the next 72 hours (Sunday,
> > > October 23, 2016 at 10am EST), I will assume lazy consensus and add it
> to
> > > the index.
> > >
> >
> >
> >
> > --
> > Robert Dale
> >
>


Re: [DISCUSS] Add neo4j-gremlin-bolt to provider index

2016-10-26 Thread Stephen Mallette
it's already on the home page

https://github.com/SteelBridgeLabs/neo4j-gremlin-bolt

On Wed, Oct 26, 2016 at 3:48 PM, Robert Dale  wrote:

> Stephen, when this is added, could you send out the URL?  Thanks.
>
> On Thu, Oct 20, 2016 at 9:58 AM, Stephen Mallette 
> wrote:
>
> > It looks like neo4j-gremlin-bolt meets our policy for adding it to our
> > provider index. I asked the maintainer if he'd like it added and the
> answer
> > was "yes". Unless there are objections in the next 72 hours (Sunday,
> > October 23, 2016 at 10am EST), I will assume lazy consensus and add it to
> > the index.
> >
>
>
>
> --
> Robert Dale
>


Re: [DISCUSS] Add neo4j-gremlin-bolt to provider index

2016-10-26 Thread Robert Dale
Stephen, when this is added, could you send out the URL?  Thanks.

On Thu, Oct 20, 2016 at 9:58 AM, Stephen Mallette 
wrote:

> It looks like neo4j-gremlin-bolt meets our policy for adding it to our
> provider index. I asked the maintainer if he'd like it added and the answer
> was "yes". Unless there are objections in the next 72 hours (Sunday,
> October 23, 2016 at 10am EST), I will assume lazy consensus and add it to
> the index.
>



-- 
Robert Dale


[jira] [Commented] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609015#comment-15609015
 ] 

ASF GitHub Bot commented on TINKERPOP-1527:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/464
  
Not sure why travis is unhappy - looks like some maven nonsense - anyway 
all tests pass with `docker/build.sh -t -i`

VOTE +1


> Do not override registered strategies in TraversalStrategies.GlobalCache
> 
>
> Key: TINKERPOP-1527
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1527
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> This may be a non-issue (need to check), but we currently do this in every 
> {{Graph}} (and {{GraphComputer}}) class.
> {code}
> static {
> TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, 
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> If this static code is loaded every time a {{Graph}} instance is created, 
> then manually tweaked strategy registrations get overwritten. If this is the 
> case, then we should do:
> {code}
> static {
> 
> TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> That is, add a {{registerIfNotPresent()}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] tinkerpop issue #464: TINKERPOP-1527: Do not override registered strategies ...

2016-10-26 Thread spmallette
Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/464
  
Not sure why travis is unhappy - looks like some maven nonsense - anyway 
all tests pass with `docker/build.sh -t -i`

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] [Created] (TINKERPOP-1530) Consistent use of instance()

2016-10-26 Thread stephen mallette (JIRA)
stephen mallette created TINKERPOP-1530:
---

 Summary: Consistent use of instance()
 Key: TINKERPOP-1530
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1530
 Project: TinkerPop
  Issue Type: Improvement
  Components: driver, io, structure
Affects Versions: 3.2.3
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor
 Fix For: 3.2.4


We have indiscriminate use of various versions of {{instance()}} (e.g. 
{{getInstance()}} - make it all consistent. Implementing this should use 
deprecation so as not to be breaking.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TINKERPOP-1525) Plug VertexProgram iteration leak on empty Spark RDD partitions

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608588#comment-15608588
 ] 

ASF GitHub Bot commented on TINKERPOP-1525:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
VOTE +1


> Plug VertexProgram iteration leak on empty Spark RDD partitions
> ---
>
> Key: TINKERPOP-1525
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1525
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Dan LaRocque
>
> If SparkExecutor gets an RDD with empty partitions, it can invoke 
> {{VertexProgram.workerIterationStart}} without ever invoking 
> {{VertexProgram.workerIterationEnd}}.
> For vertex programs that allocate and release meaningful resources in the 
> start/end methods, this can lead to resource leaks.
> I already tested a fix that I made against the 3.2 series.  I will submit PRs 
> momentarily.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TINKERPOP-1527) Do not override registered strategies in TraversalStrategies.GlobalCache

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608584#comment-15608584
 ] 

ASF GitHub Bot commented on TINKERPOP-1527:
---

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/464
  
VOTE +1


> Do not override registered strategies in TraversalStrategies.GlobalCache
> 
>
> Key: TINKERPOP-1527
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1527
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> This may be a non-issue (need to check), but we currently do this in every 
> {{Graph}} (and {{GraphComputer}}) class.
> {code}
> static {
> TraversalStrategies.GlobalCache.registerStrategies(TinkerGraph.class, 
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> If this static code is loaded every time a {{Graph}} instance is created, 
> then manually tweaked strategy registrations get overwritten. If this is the 
> case, then we should do:
> {code}
> static {
> 
> TraversalStrategies.GlobalCache.registerStrategiesIfNotPresent(TinkerGraph.class,TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(TinkerGraphStepStrategy.instance()));
> }
> {code}
> That is, add a {{registerIfNotPresent()}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (TINKERPOP-1081) Add serializers for Graph.Features

2016-10-26 Thread stephen mallette (JIRA)

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1081:

Component/s: (was: server)

> Add serializers for Graph.Features
> --
>
> Key: TINKERPOP-1081
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1081
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.0-incubating
>Reporter: Bob Briody
>Priority: Trivial
>
> Gremlin Server should provide support for the serialization of Graph.Features 
> via 'graph.features()'.
> Ideally, all Graph.Features implementations would be coerced and serialized 
> uniformly and without any work on the part of the underlying graph 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] tinkerpop issue #464: TINKERPOP-1527: Do not override registered strategies ...

2016-10-26 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/464
  
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-1476) TinkerGraph does not get typed with the right type name in GraphSON

2016-10-26 Thread stephen mallette (JIRA)

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1476.
---
   Resolution: Fixed
 Assignee: stephen mallette
Fix Version/s: 3.2.3

This was actually fixed on 3.2.3

> TinkerGraph does not get typed with the right type name in GraphSON
> ---
>
> Key: TINKERPOP-1476
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1476
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Kevin Gallardo
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.3
>
>
> TinkerGraph serialized in GraphSON2 gets typed to {{gremlin:graph}} which is 
> not consistent with the other {{g:Xxx}} types.
> For reference the code concerned is: 
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerIoRegistryV2d0.java#L124-L134



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TINKERPOP-919) Features needs to specify whether 2 vertex properties with same key/value is allowed.

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608586#comment-15608586
 ] 

ASF GitHub Bot commented on TINKERPOP-919:
--

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/463
  
VOTE +1


> Features needs to specify whether 2 vertex properties with same key/value is 
> allowed.
> -
>
> Key: TINKERPOP-919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-919
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure, test-suite, tinkergraph
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>
> TinkerGraph does not support two vertex properties with the same key/value.
> {code}
> gremlin> graph = TinkerGraph.open()
> ==>tinkergraph[vertices:0 edges:0]
> gremlin> v = graph.addVertex()
> ==>v[0]
> gremlin> v.property("name","marko")
> ==>vp[name->marko]
> gremlin> v.property("name","marko")
> ==>vp[name->marko]
> gremlin> v.properties("name")
> ==>vp[name->marko]
> {code}
> I just noted we don't have this as a {{Feature}} and we should (w/ respective 
> test cases).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] tinkerpop issue #458: Message scope initialization in PeerPressureVertexProg...

2016-10-26 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/458
  
A! Interesting. This has been a thorn in our side for some time.

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.
---


[GitHub] tinkerpop issue #462: TINKERPOP-1525 Avoid starting VP worker iterations tha...

2016-10-26 Thread okram
Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/462
  
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-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608564#comment-15608564
 ] 

ASF GitHub Bot commented on TINKERPOP-1507:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/460


> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3, 3.3.0
>
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Project step has no public getter for projectKeys

2016-10-26 Thread Marko Rodriguez
Hi,

There is no reason save that we haven’t run into a Strategy that needs them. 
The philosophy has typically been — if no one needs it, don’t expose it. :)

Marko.

http://markorodriguez.com



> On Oct 26, 2016, at 7:14 AM, Sean Barzilay  wrote:
> 
> I have been reimplementing some steps, with project being one of them and
> i've noticed there is no public getter for the projectKeys.
> 
> Is there any reason why there isn't one?
> should I just add it myself and open a PR?



[jira] [Created] (TINKERPOP-1529) LazyBarrierStrategy is too agressive

2016-10-26 Thread Daniel Kuppitz (JIRA)
Daniel Kuppitz created TINKERPOP-1529:
-

 Summary: LazyBarrierStrategy is too agressive
 Key: TINKERPOP-1529
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1529
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.3
Reporter: Daniel Kuppitz


There are scenarios where {{LazyBarrierStrategy}} changes the semantics of a 
traversal:

{noformat}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().store("a").out().select("a")
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
{noformat}

This is actually not the result of {{store()}}, this is {{aggregate()}}. The 
expected result for {{store()}} would be:

{noformat}
==>[v[1]]
==>[v[1],v[2]]
==>[v[1],v[2],v[3]]
==>[v[1],v[2],v[3],v[4]]
==>[v[1],v[2],v[3],v[4],v[5]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
{noformat}

Another issue, which should probably go into another ticket, is this:

{noformat}
gremlin> 
g.withoutStrategies(LazyBarrierStrategy).V().store("a").out().select("a")
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
{noformat}

That's it, the console is hanging at this point. Looks like 
{{PathRetractionStrategy}} is the remaining troublemaker. But even if both 
strategies are excluded, the result is still not what I would expect:

{noformat}
gremlin> g.withoutStrategies(LazyBarrierStrategy, 
PathRetractionStrategy).V().store("a").out().select("a")
==>[v[1]]
==>[v[1]]
==>[v[1]]
==>[v[1],v[2],v[3],v[4]]
==>[v[1],v[2],v[3],v[4]]
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608333#comment-15608333
 ] 

ASF GitHub Bot commented on TINKERPOP-1507:
---

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/460
  
VOTE: +1


> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TINKERPOP-1235) Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest

2016-10-26 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15608328#comment-15608328
 ] 

ASF GitHub Bot commented on TINKERPOP-1235:
---

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/465
  
Nice, looks good.

VOTE: +1


> Remove deprecated ProcessPerformanceSuite and TraversalPerformanceTest
> --
>
> Key: TINKERPOP-1235
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1235
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.0-incubating
>Reporter: Ted Wilmes
>Priority: Minor
>  Labels: breaking, deprecation
>
> The JUnit Benchmark based performance tests were deprecated for 
> 3.2.0-incubating given: TINKERPOP-1016 and TINKERPOP-1273



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] tinkerpop issue #465: TINKERPOP-1235 Removed deprecated "performance" tests.

2016-10-26 Thread twilmes
Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/465
  
Nice, looks good.

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.
---


Re: PathRetractionStrategy and TraverserRequirement.PATH

2016-10-26 Thread Marko Rodriguez
Hello Pieter,

There was a bug in RepeatStep OLAP around emit().as(‘x’) that was fixed in 
3.2.3. Perhaps it is related…

Marko.

http://markorodriguez.com



> On Oct 26, 2016, at 3:44 AM, pieter-gmail  wrote:
> 
> Thanks, now I know Sqlg has indeed been bugged. I am loosing the label
> after the emit().as("b").
> 
> Cheers
> Pieter
> 
> On 25/10/2016 21:29, Marko Rodriguez wrote:
>> Here is a simple test. Remove PathRetractionStrategy from TinkerGraph 
>> traversal and see what you get? Do you get what Sqlg returns or the same as 
>> if with PathRetractionStrategy.
>> 
>> E.g.
>> 
>> graph = TinkerFactory.createModern();
>> g = graph.traversal().withoutStrategies(PathRetractionStrategy.class);
>> g.V().the().traversal().to().test()
>> 
>> If you get the same answer without PathRetractionStrategy, then you know 
>> that Sqlg is bugged.
>> 
>> HTH,
>> Marko.
>> 
>> http://markorodriguez.com
>> 
>> 
>> 
>>> On Oct 24, 2016, at 2:21 PM, pieter-gmail  wrote:
>>> 
>>> Ok apologies. I thought I spotted the difference and simplified the
>>> gremlin too much to highlight what I thought I saw. The above mentioned
>>> queries are returning the same result in Sqlg as TinkerGraph.
>>> 
>>> Here is what is not working.
>>> 
>>>   final TinkerGraph g = TinkerFactory.createModern();
>>>   GraphTraversal>
>>> traversal = g.traversal()
>>>   .V().as("a")
>>>   .repeat(both()).times(3).emit().as("b")
>>>   .group().by(select("a"));
>>>   printTraversalForm(traversal);
>>>   while (traversal.hasNext()) {
>>>   Map vertexMap = traversal.next();
>>>   for (Vertex vertex : vertexMap.keySet()) {
>>>   Collection coll = vertexMap.get(vertex);
>>>   System.out.println("key: " + vertex.value("name") + ",
>>> value: " + coll.size());
>>>   }
>>>   }
>>> 
>>> For this Sqlg has the same result as TinkerGraph.
>>> 
>>> TinkerGraph
>>> 
>>> post-strategy:[TinkerGraphStep(vertex,[])@[a],
>>> RepeatStep([VertexStep(BOTH,vertex),
>>> RepeatEndStep],until(loops(3)),emit(true))@[b],
>>> GroupStep([SelectOneStep(a), NoOpBarrierStep(2500)],[FoldStep])]
>>> 
>>> Sqlg
>>> 
>>> post-strategy:[SqlgGraphStepCompiled(vertex,[])@[sqlgPathFakeLabel],
>>> GroupStep([SelectOneStep(a)],[FoldStep])]
>>> 
>>> key: marko, value: 27
>>> key: vadas, value: 11
>>> key: lop, value: 27
>>> key: josh, value: 27
>>> key: ripple, value: 11
>>> key: peter, value: 11
>>> 
>>> Adding in the extra by()
>>> 
>>>   final TinkerGraph g = TinkerFactory.createModern();
>>>   GraphTraversal>
>>> traversal = g.traversal()
>>>   .V().as("a")
>>>   .repeat(both()).times(3).emit().as("b")
>>>   .group().by(select("a"))
>>>   .by(select("b").dedup().order().by(T.id).fold());
>>>   printTraversalForm(traversal);
>>>   while (traversal.hasNext()) {
>>>   Map vertexMap = traversal.next();
>>>   for (Vertex vertex : vertexMap.keySet()) {
>>>   Collection coll = vertexMap.get(vertex);
>>>   System.out.println("key: " + vertex.value("name") + ",
>>> value: " + coll.size());
>>>   }
>>>   }
>>> 
>>> TinkerGraph prints
>>> 
>>> post-strategy:[TinkerGraphStep(vertex,[])@[a],
>>> RepeatStep([VertexStep(BOTH,vertex),
>>> RepeatEndStep],until(loops(3)),emit(true))@[b],
>>> GroupStep([SelectOneStep(a), NoOpBarrierStep(2500)],[SelectOneStep(b),
>>> DedupGlobalStep, OrderGlobalStep([[id, incr]]), FoldStep])]
>>> 
>>> key: marko, value: 6
>>> key: vadas, value: 6
>>> key: lop, value: 6
>>> key: josh, value: 6
>>> key: ripple, value: 6
>>> key: peter, value: 6
>>> 
>>> and Sqlg
>>> 
>>> post-strategy:[SqlgGraphStepCompiled(vertex,[])@[sqlgPathFakeLabel],
>>> GroupStep([SelectOneStep(a)],[SelectOneStep(b), DedupGlobalStep,
>>> OrderGlobalStep([[id, incr]]), FoldStep])]
>>> 
>>> key: marko, value: 0
>>> key: ripple, value: 0
>>> key: peter, value: 0
>>> key: lop, value: 0
>>> key: josh, value: 0
>>> key: vadas, value: 0
>>> 
>>> The difference being the NoOpBarrierStep but I am not sure if that is
>>> the culprit or not.
>>> 
>>> Thanks
>>> Pieter
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 24/10/2016 21:31, Marko Rodriguez wrote:
 Hi Pieter,
 
 What are the two answers --- TinkerGraph and Sqlg for the respective test 
 traversal?
 
 (I suspect the test is bad because group() pushes traversers through with 
 bulks and all so the test might just add to a collection without adding 
 respecting bulks. Probably should change that test regardless to do like a 
 count or something instead).
 
 Marko.
 
 http://markorodriguez.com
 
 
 
> On Oct 24, 2016, at 12:57 PM, pieter-gmail  
> wrote:
> 
> Hi,

Re: PathRetractionStrategy and TraverserRequirement.PATH

2016-10-26 Thread pieter-gmail
Thanks, now I know Sqlg has indeed been bugged. I am loosing the label
after the emit().as("b").

Cheers
Pieter

On 25/10/2016 21:29, Marko Rodriguez wrote:
> Here is a simple test. Remove PathRetractionStrategy from TinkerGraph 
> traversal and see what you get? Do you get what Sqlg returns or the same as 
> if with PathRetractionStrategy.
>
> E.g.
>
> graph = TinkerFactory.createModern();
> g = graph.traversal().withoutStrategies(PathRetractionStrategy.class);
> g.V().the().traversal().to().test()
>
> If you get the same answer without PathRetractionStrategy, then you know that 
> Sqlg is bugged.
>
> HTH,
> Marko.
>
> http://markorodriguez.com
>
>
>
>> On Oct 24, 2016, at 2:21 PM, pieter-gmail  wrote:
>>
>> Ok apologies. I thought I spotted the difference and simplified the
>> gremlin too much to highlight what I thought I saw. The above mentioned
>> queries are returning the same result in Sqlg as TinkerGraph.
>>
>> Here is what is not working.
>>
>>final TinkerGraph g = TinkerFactory.createModern();
>>GraphTraversal>
>> traversal = g.traversal()
>>.V().as("a")
>>.repeat(both()).times(3).emit().as("b")
>>.group().by(select("a"));
>>printTraversalForm(traversal);
>>while (traversal.hasNext()) {
>>Map vertexMap = traversal.next();
>>for (Vertex vertex : vertexMap.keySet()) {
>>Collection coll = vertexMap.get(vertex);
>>System.out.println("key: " + vertex.value("name") + ",
>> value: " + coll.size());
>>}
>>}
>>
>> For this Sqlg has the same result as TinkerGraph.
>>
>> TinkerGraph
>>
>> post-strategy:[TinkerGraphStep(vertex,[])@[a],
>> RepeatStep([VertexStep(BOTH,vertex),
>> RepeatEndStep],until(loops(3)),emit(true))@[b],
>> GroupStep([SelectOneStep(a), NoOpBarrierStep(2500)],[FoldStep])]
>>
>> Sqlg
>>
>> post-strategy:[SqlgGraphStepCompiled(vertex,[])@[sqlgPathFakeLabel],
>> GroupStep([SelectOneStep(a)],[FoldStep])]
>>
>> key: marko, value: 27
>> key: vadas, value: 11
>> key: lop, value: 27
>> key: josh, value: 27
>> key: ripple, value: 11
>> key: peter, value: 11
>>
>> Adding in the extra by()
>>
>>final TinkerGraph g = TinkerFactory.createModern();
>>GraphTraversal>
>> traversal = g.traversal()
>>.V().as("a")
>>.repeat(both()).times(3).emit().as("b")
>>.group().by(select("a"))
>>.by(select("b").dedup().order().by(T.id).fold());
>>printTraversalForm(traversal);
>>while (traversal.hasNext()) {
>>Map vertexMap = traversal.next();
>>for (Vertex vertex : vertexMap.keySet()) {
>>Collection coll = vertexMap.get(vertex);
>>System.out.println("key: " + vertex.value("name") + ",
>> value: " + coll.size());
>>}
>>}
>>
>> TinkerGraph prints
>>
>> post-strategy:[TinkerGraphStep(vertex,[])@[a],
>> RepeatStep([VertexStep(BOTH,vertex),
>> RepeatEndStep],until(loops(3)),emit(true))@[b],
>> GroupStep([SelectOneStep(a), NoOpBarrierStep(2500)],[SelectOneStep(b),
>> DedupGlobalStep, OrderGlobalStep([[id, incr]]), FoldStep])]
>>
>> key: marko, value: 6
>> key: vadas, value: 6
>> key: lop, value: 6
>> key: josh, value: 6
>> key: ripple, value: 6
>> key: peter, value: 6
>>
>> and Sqlg
>>
>> post-strategy:[SqlgGraphStepCompiled(vertex,[])@[sqlgPathFakeLabel],
>> GroupStep([SelectOneStep(a)],[SelectOneStep(b), DedupGlobalStep,
>> OrderGlobalStep([[id, incr]]), FoldStep])]
>>
>> key: marko, value: 0
>> key: ripple, value: 0
>> key: peter, value: 0
>> key: lop, value: 0
>> key: josh, value: 0
>> key: vadas, value: 0
>>
>> The difference being the NoOpBarrierStep but I am not sure if that is
>> the culprit or not.
>>
>> Thanks
>> Pieter
>>
>>
>>
>>
>>
>>
>> On 24/10/2016 21:31, Marko Rodriguez wrote:
>>> Hi Pieter,
>>>
>>> What are the two answers --- TinkerGraph and Sqlg for the respective test 
>>> traversal?
>>>
>>> (I suspect the test is bad because group() pushes traversers through with 
>>> bulks and all so the test might just add to a collection without adding 
>>> respecting bulks. Probably should change that test regardless to do like a 
>>> count or something instead).
>>>
>>> Marko.
>>>
>>> http://markorodriguez.com
>>>
>>>
>>>
 On Oct 24, 2016, at 12:57 PM, pieter-gmail  wrote:

 Hi,

 This is on 3.2.3

 I have been investigating why
 `DedupTest.g_V_asXaX_repeatXbothX_timesX3X_emit_asXbX_group_byXselectXaXX_byXselectXbX_dedup_order_byXidX_foldX_selectXvaluesX_unfold_dedup`
 fails on Sqlg. It is a fairly recently added test.

 My investigation so far has narrowed the problem to the
 `PathRetractionStrategy`

 On the modern graph,