Re: Code Freeze 3.2.3/3.1.5

[Stephen Mallette]

Push a commit to master earlier today to fix that issue we talked about
last week regarding the failing TraversalInterruptionTest. Travis has been
happy and I can't seem to get it to fail locally. I think it's in good
shape. If you were having problems with that before, please give it a try
now. Marko is still planning to some work to fix up PeerPressure test
(can't say I've have trouble with that one myself).

Also, I published a 3.2.3 -SNAPSHOT earlier today btw to the Apache
snapshot repository for testing.

On Fri, Oct 7, 2016 at 6:44 PM, Stephen Mallette 
wrote:

> We're supposed to start code freeze tomorrow, but we are a little behind.
> Still have one PR left to merge and it needs a rebase:
>
> https://github.com/apache/tinkerpop/pull/448
>
> So expect that to get merged for 3.2.3 during code freeze week, but
> nothing in that PR should preclude providers from testing their
> implementations.  Other than that, I think everything else of substance is
> in.
>
> I do have one worry about that TraversalInterruption test that has been
> failing randomly since the LazyBarrierStrategy stuff went in (i think).
> Marko also mentioned the PeerPressure test. We'll put some elbow grease
> into that next week and try to get those figured out and more stable.
>
> As a reminder Ted will be release manager for 3.1.5 and I'll be doing
> 3.2.3. As usual, we will use this thread to coordinate during code freeze
> week. Please bring up relevant issues here.
>
> Thanks,
>
> Stephen
>

[jira] [Commented] (TINKERPOP-1469) Get rid of Stream-usage in TraversalHelper

[ASF GitHub Bot (JIRA)]

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

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

Github user okram closed the pull request at:

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


> Get rid of Stream-usage in TraversalHelper
> --
>
> Key: TINKERPOP-1469
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1469
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> There are lots of {{Stream}}-usages in {{TraversalHelper}}. Given that 
> {{TraversalHelper}} is used extensively in the various traversal strategies 
> (thus, compile time), it would be good to gut such stream usage to make 
> things as efficient as possible.



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

[GitHub] tinkerpop pull request #454: TINKERPOP-1469: Get rid of Stream-usage in Trav...

[okram]

Github user okram closed the pull request at:

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


---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
Let's get 3.1.x fixed also. I don't see why not.


> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #456: TINKERPOP-1493 Groovy project doesn't build on Windows

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
Let's get 3.1.x fixed also. I don't see why not.


---
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-1440) g:Path needs a GraphSON deserializer in Gremlin-Python

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1440.
---
Resolution: Done

> g:Path needs a GraphSON deserializer in Gremlin-Python
> --
>
> Key: TINKERPOP-1440
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1440
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>




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

[jira] [Commented] (TINKERPOP-1493) Groovy project doesn't build on Windows

[Paul Jackson (JIRA)]

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

Paul Jackson commented on TINKERPOP-1493:
-

I created a pull request. Feedback welcome. I don't think I could assign the 
issue to myself so I left this unresolved. Thanks.

> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[GitHub] tinkerpop issue #456: TINKERPOP-1493 Groovy project doesn't build on Windows

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/456
  
Not sure if it matters, but if we only bring this change to master, 3.1.x 
won't build on windows and the process will have diverged. not sure if we 
should let that happen. @pluradj do you have an opinion? 


---
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 #456: TINKERPOP-1493 Groovy project doesn't build on ...

[pauljackson]

GitHub user pauljackson opened a pull request:

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

TINKERPOP-1493 Groovy project doesn't build on Windows

Removed support for user.dir property as it was being prepended to a
fully qualified path and the second drive letter was making the path
illegal.

Made sure JarFile instances were being closed so that Groovy could
delete the directory without encountering file locked errors.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pauljackson/tinkerpop master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/456.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #456


commit de571c5a47138e4445e91bcf7897839ff6bf49f2
Author: PaulJackson123 
Date:   2016-10-11T20:15:40Z

TINKERPOP-1493 Groovy project doesn't build on Windows

Removed support for user.dir property as it was being prepended to a
fully qualified path and the second drive letter was making the path
illegal.

Made sure JarFile instances were being closed so that Groovy could
delete the directory without encountering file locked errors.




---
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-1493) Groovy project doesn't build on Windows

[ASF GitHub Bot (JIRA)]

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

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

GitHub user pauljackson opened a pull request:

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

TINKERPOP-1493 Groovy project doesn't build on Windows

Removed support for user.dir property as it was being prepended to a
fully qualified path and the second drive letter was making the path
illegal.

Made sure JarFile instances were being closed so that Groovy could
delete the directory without encountering file locked errors.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pauljackson/tinkerpop master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/456.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #456


commit de571c5a47138e4445e91bcf7897839ff6bf49f2
Author: PaulJackson123 
Date:   2016-10-11T20:15:40Z

TINKERPOP-1493 Groovy project doesn't build on Windows

Removed support for user.dir property as it was being prepended to a
fully qualified path and the second drive letter was making the path
illegal.

Made sure JarFile instances were being closed so that Groovy could
delete the directory without encountering file locked errors.




> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[jira] [Reopened] (TINKERPOP-1440) g:Path needs a GraphSON deserializer in Gremlin-Python

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1440:
-

Re-opening to change the resolution to one we use regularly.

> g:Path needs a GraphSON deserializer in Gremlin-Python
> --
>
> Key: TINKERPOP-1440
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1440
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>




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

[jira] [Closed] (TINKERPOP-1469) Get rid of Stream-usage in TraversalHelper

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1469.
-
   Resolution: Fixed
Fix Version/s: 3.2.3

> Get rid of Stream-usage in TraversalHelper
> --
>
> Key: TINKERPOP-1469
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1469
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> There are lots of {{Stream}}-usages in {{TraversalHelper}}. Given that 
> {{TraversalHelper}} is used extensively in the various traversal strategies 
> (thus, compile time), it would be good to gut such stream usage to make 
> things as efficient as possible.



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

[GitHub] tinkerpop issue #448: Python glv graphson update

[aholmberg]

Github user aholmberg commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
Pushed the split names. I didn't see issues related to these changes 
running `process-docs.sh`.
May have been related to the previous removal of GraphSONWriter/Reader.


---
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 #454: TINKERPOP-1469: Get rid of Stream-usage in TraversalHe...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/454
  
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 #448: Python glv graphson update

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
> Maybe we should clarify what APIs really need to be preserved.

imo i think that could be debated. at this point, i think being sorta 
cautious and following what's been working for a java though seems prudent. 
thanks for re-working.


---
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-1189) SimpleAuthenticator over HttpChannelizer makes Gremlin Server pretty slow and consumes more CPU

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/452
  
Merged this via CTR - pretty straightforward - thanks.


> SimpleAuthenticator over HttpChannelizer makes Gremlin Server pretty slow and 
> consumes more CPU
> ---
>
> Key: TINKERPOP-1189
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1189
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
> Environment: Gremlin Server 3.0.2 backended by Titan 1.0.0 and 
> Cassandra (separate instance), running in a server with 2 CPUs / 7.5 GB RAM 
> (Linux Debian 3.16.7)
>Reporter: Gabriel Moreira
>Assignee: stephen mallette
>Priority: Minor
>
> I have setup Authorization in my Gremlin Server instances (v3.0.2), backended 
> by Titan v1.0.0 and Cassandra.
> I am testing SimpleAuthenticator, with the following snippet from my 
> gremlin-server.yaml:
> authentication: {
>   className: org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator,
>   config: {
> credentialsDb: conf/tinkergraph-empty.properties,
> credentialsDbLocation: data/credentials.kryo}}
> ssl: {
>   enabled: false}
> I am using the default serialization file of TinkerGraph credentials.kryo, 
> with only the default user stephen/password.
>  I am using Basic Auth in my requests to Gremlin Server, by passing the 
> header "Authorization" with the value "Basic c3RlcGhlbjpwYXNzd29yZA==".
> Authorization works as expected. Therefore, the Gremlin Server becomes pretty 
> slow! It takes 10x more time and consumes 5x more CPU (from 10% to 50%) to 
> handle the same simple traversal Http POST request (below) in batch, compared 
> to Gremlin Server with NO authorization!
> {
> "gremlin": "g.V().has('CONTENT','id', 'LinkPost:7330001').count()"
> }
> Is there a workaround to this?
> Ps. If there is a fix, could it be patched for version 3.0.2? I am limited to 
> this version because I use Titan 1.0.0.
> Thanks.
> Gabriel Moreira



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

[jira] [Commented] (TINKERPOP-1189) SimpleAuthenticator over HttpChannelizer makes Gremlin Server pretty slow and consumes more CPU

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> SimpleAuthenticator over HttpChannelizer makes Gremlin Server pretty slow and 
> consumes more CPU
> ---
>
> Key: TINKERPOP-1189
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1189
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
> Environment: Gremlin Server 3.0.2 backended by Titan 1.0.0 and 
> Cassandra (separate instance), running in a server with 2 CPUs / 7.5 GB RAM 
> (Linux Debian 3.16.7)
>Reporter: Gabriel Moreira
>Assignee: stephen mallette
>Priority: Minor
>
> I have setup Authorization in my Gremlin Server instances (v3.0.2), backended 
> by Titan v1.0.0 and Cassandra.
> I am testing SimpleAuthenticator, with the following snippet from my 
> gremlin-server.yaml:
> authentication: {
>   className: org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator,
>   config: {
> credentialsDb: conf/tinkergraph-empty.properties,
> credentialsDbLocation: data/credentials.kryo}}
> ssl: {
>   enabled: false}
> I am using the default serialization file of TinkerGraph credentials.kryo, 
> with only the default user stephen/password.
>  I am using Basic Auth in my requests to Gremlin Server, by passing the 
> header "Authorization" with the value "Basic c3RlcGhlbjpwYXNzd29yZA==".
> Authorization works as expected. Therefore, the Gremlin Server becomes pretty 
> slow! It takes 10x more time and consumes 5x more CPU (from 10% to 50%) to 
> handle the same simple traversal Http POST request (below) in batch, compared 
> to Gremlin Server with NO authorization!
> {
> "gremlin": "g.V().has('CONTENT','id', 'LinkPost:7330001').count()"
> }
> Is there a workaround to this?
> Ps. If there is a fix, could it be patched for version 3.0.2? I am limited to 
> this version because I use Titan 1.0.0.
> Thanks.
> Gabriel Moreira



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

[GitHub] tinkerpop pull request #452: TINKERPOP-1189 Increased performance of Credent...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #448: Python glv graphson update

[aholmberg]

Github user aholmberg commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
Maybe we should clarify what APIs really need to be preserved. I have been 
thinking about the `process` package, and `structure` module as the Gremlin 
API, and the `driver` and `io` as distinct integrations.

I'm working on splitting reader/writer now, but I'm not convinced this API 
is worth replicating here. We can chalk it up to my ignorance of the greater 
ecosystem machinery.


---
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 #448: Python glv graphson update

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
@aholmberg We have had a distinction between reader/writer since the 
beginning of TinkerPop. I believe (@spmallette knows more) that there is a 
`GryoMapper` class that has all the serializers registered. Thus, both reader 
and writer have reference to a `GryoMapper`.


---
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 #448: Python glv graphson update

[aholmberg]

Github user aholmberg commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
Thanks. I see the code there. What is not clear to me is why these two 
things are divided, and why that API should be replicated here. I'm having a 
hard time doing this change because it makes it more cumbersome to use (at 
least for the integration I'm considering). 

I can vaguely imagine using readers and writers in a migration scenario 
where input and output are different. Can you help me understand the use case 
in the context of this GLV, where client IO uses a single format?


---
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-1469) Get rid of Stream-usage in TraversalHelper

[ASF GitHub Bot (JIRA)]

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

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

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/454
  
The conversions and additional changes all look good.

VOTE: +1


> Get rid of Stream-usage in TraversalHelper
> --
>
> Key: TINKERPOP-1469
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1469
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are lots of {{Stream}}-usages in {{TraversalHelper}}. Given that 
> {{TraversalHelper}} is used extensively in the various traversal strategies 
> (thus, compile time), it would be good to gut such stream usage to make 
> things as efficient as possible.



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

[GitHub] tinkerpop issue #454: TINKERPOP-1469: Get rid of Stream-usage in TraversalHe...

[twilmes]

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/454
  
The conversions and additional changes all look 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.
---

[jira] [Commented] (TINKERPOP-1498) choose() can throw StackOverflowErrors

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1498:
---

With these changes:

{code}
public final class BulkSet extends AbstractSet implements Set, 
Serializable {
private final Map map;

public BulkSet() {
this(new LinkedHashMap<>());
}

private BulkSet(final Map map) {
this.map = map;
}

...

public boolean add(final S s, final long bulk) {
final S item = Objects.equals(s, this) ? (S) new BulkSet<>(new 
LinkedHashMap<>(map)) : s;
final Long current = this.map.get(s);
if (current != null) {
this.map.put(item, current + bulk);
return false;
} else {
this.map.put(item, bulk);
return true;
}
}

...
}
{code}

...I get:

{noformat}
gremlin> __.inject(1,2,3).choose(select("x").count(local).is(gt(0)), 
select("x"), constant("x")).store("x")
==>x
==>{x=1, {x=1}=1}
==>{x=1, {x=1}=1, {x=1, {x=1}=1}=1}
{noformat}

Do we like that?

> choose() can throw StackOverflowErrors
> --
>
> Key: TINKERPOP-1498
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1498
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().choose(select("x"), select("x"), constant("not x")).store("x")
> java.lang.StackOverflowError
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}



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

[jira] [Commented] (TINKERPOP-1495) Global list deduplication doesn't work in OLAP

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1495:
---

The problem is with {{emit()}} in {{RepeatStep}} in OLAP. 

I fixed the dedup issue in this branch. I'll see whats up with {{repeat()}} 
(perhaps its an OLAP traverser bulk side-effect).

> Global list deduplication doesn't work in OLAP
> --
>
> Key: TINKERPOP-1495
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1495
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> a = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> gremlin> 
> g.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> gremlin> 
> a.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[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[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5]]
> gremlin>
> {noformat}
> _Not tested in {{tp31}}._



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

[jira] [Commented] (TINKERPOP-1498) choose() can throw StackOverflowErrors

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1498:
---

Can you add a bit more information please.

1.) the stack trace.
2.) a test case.
3.) does this work with previous versions.

I looked at the stack trace and it seems that this is a Groovy issue not being 
able to resolve a method... 

> choose() can throw StackOverflowErrors
> --
>
> Key: TINKERPOP-1498
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1498
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().choose(select("x"), select("x"), constant("not x")).store("x")
> java.lang.StackOverflowError
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}



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

[jira] [Commented] (TINKERPOP-1496) Should a head-as("x") always be a select("x")?

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1496:
---

I like the idea. In the end it should be the same thing with less code. 
However, it only *should* be the same thing, but it's not:

{noformat}
gremlin> g.V().as("a").both().as("a").where(__.as("a").has("lang","java"))
==>v[3]
==>v[3]
==>v[3]
==>v[5]
gremlin> g.V().as("a").both().as("a").where(select("a").has("lang","java"))
java.util.ArrayList cannot be cast to 
org.apache.tinkerpop.gremlin.structure.Element
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}

The correct translation is {{select(last, "x")}}.

> Should a head-as("x") always be a select("x")?
> --
>
> Key: TINKERPOP-1496
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1496
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> There are two steps that treat a head of {{as("x")}} as {{select("x")}}. 
> {code}
> match(as("x").out().as("y"), ...) => match(select("x").out().as("y"), ...)
> where(as("x").has("name")) => where(select("x").has("name"))
> {code}
> I don't like how these steps are "special" in this respect and I think that 
> it would be elegant if a head-{{as()}} has a consistent meaning for all inner 
> traversals.
> Thus, I'm wondering if we should make it such that EVERY head {{as("x")}} 
> gets translated to {{select("x")}}.
> {code}
> addE("knows").to(as("x").out("mother"))
> property("name", as("x").out("mother").values("name"))
> {code}
> I believe this would be backwards compatible in the sense that there really 
> isn't a reason why an inner traversal head-{{as()}} would be used to label. 
> Dunno -- definitely need [~dkuppitz]/etc. feedback.



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

[jira] [Commented] (TINKERPOP-1495) Global list deduplication doesn't work in OLAP

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1495:
---

So I got it working, but then [~dkuppitz] query isn't working as expected. 
However, I think its a different bug in that query related to {{select()}} in 
{{group()}}! Dah!. not sure. Created a branch with the kuppitz test 
commented out.

> Global list deduplication doesn't work in OLAP
> --
>
> Key: TINKERPOP-1495
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1495
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> a = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> gremlin> 
> g.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> gremlin> 
> a.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[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[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5]]
> gremlin>
> {noformat}
> _Not tested in {{tp31}}._



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

[jira] [Created] (TINKERPOP-1498) choose() can throw StackOverflowErrors

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-1498:
-

 Summary: choose() can throw StackOverflowErrors
 Key: TINKERPOP-1498
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1498
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.2
Reporter: Daniel Kuppitz


{noformat}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().choose(select("x"), select("x"), constant("not x")).store("x")
java.lang.StackOverflowError
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}



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

[jira] [Commented] (TINKERPOP-1494) Means of exposing execution information from a result produced by RemoteConnection

[Bob Briody (JIRA)]

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

Bob Briody commented on TINKERPOP-1494:
---

Matthias B did the work to populate the profiling metrics info from DSEGraph. I 
put the hooks in TinkerPop's profiling framework to enable that. I'm not sure 
how useful or applicable that stuff would be as an extension model in this 
case. Connection and request details may benefit from something less abstract.

> Means of exposing execution information from a result produced by 
> RemoteConnection
> --
>
> Key: TINKERPOP-1494
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1494
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.2
>Reporter: Andy Tolbert
>
> When using a Graph Traversal that is backed by a {{RemoteConnection}} it 
> would be useful if there was a way to get information about how the traversal 
> was executed in terms of what host was used and perhaps other information 
> that is useful for that particular {{RemoteConnection}} implementation.  For 
> example, if the underlying connection executes retries on query timeouts, 
> it'd be interesting if that and the hosts that were tried were surfaced in 
> some way.



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

[jira] [Commented] (TINKERPOP-1495) Global list deduplication doesn't work in OLAP

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1495:
---

I know why this is happening. There is a simply solution and there is the real 
solution.

The problem is that the traversal goes into "local mode" after {{groupCount()}} 
and thus, until an element is seen, the traversal should be treated like an 
OLTP traversal. However, its still treated like an OLAP traversal as 
{{GraphComputing}} steps need a {{setOnGraphComputer(boolean)}} method to say 
"we are in local model, treat as OLTP."

> Global list deduplication doesn't work in OLAP
> --
>
> Key: TINKERPOP-1495
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1495
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> a = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> gremlin> 
> g.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> gremlin> 
> a.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[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[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5]]
> gremlin>
> {noformat}
> _Not tested in {{tp31}}._



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

[jira] [Commented] (TINKERPOP-1495) Global list deduplication doesn't work in OLAP

[Marc de Lignie (JIRA)]

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

Marc de Lignie commented on TINKERPOP-1495:
---

Maybe the following is handy for comparison. This works ok:

gremlin> :> g.V().map{it -> 1}.dedup()
==>1


> Global list deduplication doesn't work in OLAP
> --
>
> Key: TINKERPOP-1495
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1495
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> a = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> gremlin> 
> g.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> gremlin> 
> a.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[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[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5]]
> gremlin>
> {noformat}
> _Not tested in {{tp31}}._



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

[jira] [Commented] (TINKERPOP-1493) Groovy project doesn't build on Windows

[Paul Jackson (JIRA)]

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

Paul Jackson commented on TINKERPOP-1493:
-

Hi Jason,

I'll take a look this week.

Thanks for reviewing.

-Paul



> Groovy project doesn't build on Windows
> ---
>
> Key: TINKERPOP-1493
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
> Project: TinkerPop
>  Issue Type: Bug
>  Components: groovy
>Affects Versions: 3.2.2
>Reporter: Paul Jackson
>Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



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

[jira] [Commented] (TINKERPOP-1495) Global list deduplication doesn't work in OLAP

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1495:
---

Great. This helps alot. [~dkuppitz] Is the the "full situation" in which this 
problem occurs? That is, when you {{select(values).unfold().dedup()}} ?

{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().groupCount().select(values).unfold().dedup()
==>1
gremlin> g.withComputer().V().groupCount().select(values).unfold().dedup()
==>1
==>1
==>1
==>1
==>1
==>1
{code}

> Global list deduplication doesn't work in OLAP
> --
>
> Key: TINKERPOP-1495
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1495
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> a = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> gremlin> 
> g.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> gremlin> 
> a.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[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[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5]]
> gremlin>
> {noformat}
> _Not tested in {{tp31}}._



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

[jira] [Updated] (TINKERPOP-1356) Several issues in HasContainer

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez updated TINKERPOP-1356:
--
Assignee: (was: Marko A. Rodriguez)

> Several issues in HasContainer
> --
>
> Key: TINKERPOP-1356
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1356
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Daniel Kuppitz
>
> {{HasContainer}} has some issues that are not covered by test cases, but IMO 
> likely to happen in real world applications.
> Empty collections lead to uncaught exceptions with a meaningless error 
> message:
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().hasId(within(new ArrayList()))
> 0
> Display stack trace? [yN] N
> gremlin> g.V().hasId(without(new ArrayList()))
> 0
> Display stack trace? [yN]
> {noformat}
> In the constructor of {{HasContainer}} we should use:
> {code}
> ((Collection) 
> this.predicate.getValue()).stream().findFirst().orElseGet(Object::new)
> {code}
> ...instead of:
> {code}
> ((Collection) this.predicate.getValue()).toArray()[0]
> {code}
> ..or anything else that doesn't assume that we will always have a first 
> element.
> Furthermore {{enforceHomogenousCollectionIfPresent}} should check for empty 
> collections:
> {code}
> ...
> final Collection collection = (Collection) predicateValue;
> if (!collection.isEmpty()) { // <--
> final Class first = collection.toArray()[0].getClass();
> if (!((Collection) 
> predicateValue).stream().map(Object::getClass).allMatch(c -> first.equals(c)))
> throw new IllegalArgumentException("Has comparisons on a collection 
> of ids require ids to all be of the same type");
> }
> ...
> {code}
> And the last issue is this one (from the code snippet above): 
> {{collection.toArray()\[0\].getClass()}}. What if the first (or any other) 
> element is actually {{null}}? The check should be more like:
> {code}
> final Object obj = new Object();
> if (((Collection) predicateValue).stream().map(o -> 
> Optional.ofNullable(o).orElse(obj).getClass()).distinct().count() != 1)
> throw ...
> {code}
> Or something smarter like that, as long as it has a {{null}}-check.
> The proposed code changes seem to work fine, except for 
> {{hasId(within())}}, which emits all vertices instead of 
> none.



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

[jira] [Assigned] (TINKERPOP-1356) Several issues in HasContainer

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez reassigned TINKERPOP-1356:
-

Assignee: Marko A. Rodriguez

> Several issues in HasContainer
> --
>
> Key: TINKERPOP-1356
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1356
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> {{HasContainer}} has some issues that are not covered by test cases, but IMO 
> likely to happen in real world applications.
> Empty collections lead to uncaught exceptions with a meaningless error 
> message:
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().hasId(within(new ArrayList()))
> 0
> Display stack trace? [yN] N
> gremlin> g.V().hasId(without(new ArrayList()))
> 0
> Display stack trace? [yN]
> {noformat}
> In the constructor of {{HasContainer}} we should use:
> {code}
> ((Collection) 
> this.predicate.getValue()).stream().findFirst().orElseGet(Object::new)
> {code}
> ...instead of:
> {code}
> ((Collection) this.predicate.getValue()).toArray()[0]
> {code}
> ..or anything else that doesn't assume that we will always have a first 
> element.
> Furthermore {{enforceHomogenousCollectionIfPresent}} should check for empty 
> collections:
> {code}
> ...
> final Collection collection = (Collection) predicateValue;
> if (!collection.isEmpty()) { // <--
> final Class first = collection.toArray()[0].getClass();
> if (!((Collection) 
> predicateValue).stream().map(Object::getClass).allMatch(c -> first.equals(c)))
> throw new IllegalArgumentException("Has comparisons on a collection 
> of ids require ids to all be of the same type");
> }
> ...
> {code}
> And the last issue is this one (from the code snippet above): 
> {{collection.toArray()\[0\].getClass()}}. What if the first (or any other) 
> element is actually {{null}}? The check should be more like:
> {code}
> final Object obj = new Object();
> if (((Collection) predicateValue).stream().map(o -> 
> Optional.ofNullable(o).orElse(obj).getClass()).distinct().count() != 1)
> throw ...
> {code}
> Or something smarter like that, as long as it has a {{null}}-check.
> The proposed code changes seem to work fine, except for 
> {{hasId(within())}}, which emits all vertices instead of 
> none.



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

[jira] [Commented] (TINKERPOP-1495) Global list deduplication doesn't work in OLAP

[Marc de Lignie (JIRA)]

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

Marc de Lignie commented on TINKERPOP-1495:
---

This one looks a lot  simpler:

gremlin> graph = GraphFactory.open('conf/hadoop/hadoop-gryo.properties')
==>hadoopgraph[gryoinputformat->gryooutputformat]
gremlin> g = graph.traversal(computer(SparkGraphComputer))
==>graphtraversalsource[hadoopgraph[gryoinputformat->gryooutputformat], 
sparkgraphcomputer]
gremlin> g.V().groupCount().select(values).unfold().dedup()
==>1
==>1
==>1
==>1
==>1
==>1

In TinkerGraph this gives a single "1". OLAP via remote connection also fails.

> Global list deduplication doesn't work in OLAP
> --
>
> Key: TINKERPOP-1495
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1495
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> a = TinkerFactory.createModern().traversal().withComputer()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
> gremlin> 
> gremlin> 
> g.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> gremlin> 
> a.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
> ==>[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[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5]]
> gremlin>
> {noformat}
> _Not tested in {{tp31}}._



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

[jira] [Commented] (TINKERPOP-1469) Get rid of Stream-usage in TraversalHelper

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1469: Get rid of Stream-usage in TraversalHelper

https://issues.apache.org/jira/browse/TINKERPOP-1469

I went through `TraversalHelper` and removed all usage of `stream()` as 
well as added various other little nick-nack optimizations along the way.
I also added some more test cases to `TraversalHelperTest`.

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1469

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/454.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #454


commit 9ce3fe86979a5f3452bfcb82ed8642fa1ea291c6
Author: Marko A. Rodriguez 
Date:   2016-10-11T12:36:39Z

removed stream()-usage and unneeded method recurssions in TraversalHelper.

commit 54226cde46b5b96cf756f1b4fb8dc40086c14aec
Author: Marko A. Rodriguez 
Date:   2016-10-11T12:44:02Z

added another test case for getLabels().




> Get rid of Stream-usage in TraversalHelper
> --
>
> Key: TINKERPOP-1469
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1469
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are lots of {{Stream}}-usages in {{TraversalHelper}}. Given that 
> {{TraversalHelper}} is used extensively in the various traversal strategies 
> (thus, compile time), it would be good to gut such stream usage to make 
> things as efficient as possible.



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

[GitHub] tinkerpop pull request #454: TINKERPOP-1469: Get rid of Stream-usage in Trav...

[okram]

GitHub user okram opened a pull request:

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

TINKERPOP-1469: Get rid of Stream-usage in TraversalHelper

https://issues.apache.org/jira/browse/TINKERPOP-1469

I went through `TraversalHelper` and removed all usage of `stream()` as 
well as added various other little nick-nack optimizations along the way.
I also added some more test cases to `TraversalHelperTest`.

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1469

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/454.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #454


commit 9ce3fe86979a5f3452bfcb82ed8642fa1ea291c6
Author: Marko A. Rodriguez 
Date:   2016-10-11T12:36:39Z

removed stream()-usage and unneeded method recurssions in TraversalHelper.

commit 54226cde46b5b96cf756f1b4fb8dc40086c14aec
Author: Marko A. Rodriguez 
Date:   2016-10-11T12:44:02Z

added another test case for getLabels().




---
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] [Assigned] (TINKERPOP-1469) Get rid of Stream-usage in TraversalHelper

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez reassigned TINKERPOP-1469:
-

Assignee: Marko A. Rodriguez  (was: Ted Wilmes)

> Get rid of Stream-usage in TraversalHelper
> --
>
> Key: TINKERPOP-1469
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1469
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are lots of {{Stream}}-usages in {{TraversalHelper}}. Given that 
> {{TraversalHelper}} is used extensively in the various traversal strategies 
> (thus, compile time), it would be good to gut such stream usage to make 
> things as efficient as possible.



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

[jira] [Commented] (TINKERPOP-1494) Means of exposing execution information from a result produced by RemoteConnection

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1494:
---

[~rjbriody] Did work in DSEGraph where he extended `TraversalMetrics` to have 
DSE-specific information such as index-hit speed/etc. I believe this ticket 
would use the same extension model.

> Means of exposing execution information from a result produced by 
> RemoteConnection
> --
>
> Key: TINKERPOP-1494
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1494
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.2
>Reporter: Andy Tolbert
>
> When using a Graph Traversal that is backed by a {{RemoteConnection}} it 
> would be useful if there was a way to get information about how the traversal 
> was executed in terms of what host was used and perhaps other information 
> that is useful for that particular {{RemoteConnection}} implementation.  For 
> example, if the underlying connection executes retries on query timeouts, 
> it'd be interesting if that and the hosts that were tried were surfaced in 
> some way.



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

[jira] [Updated] (TINKERPOP-1494) Means of exposing execution information from a result produced by RemoteConnection

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1494:

Component/s: driver

> Means of exposing execution information from a result produced by 
> RemoteConnection
> --
>
> Key: TINKERPOP-1494
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1494
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.2
>Reporter: Andy Tolbert
>
> When using a Graph Traversal that is backed by a {{RemoteConnection}} it 
> would be useful if there was a way to get information about how the traversal 
> was executed in terms of what host was used and perhaps other information 
> that is useful for that particular {{RemoteConnection}} implementation.  For 
> example, if the underlying connection executes retries on query timeouts, 
> it'd be interesting if that and the hosts that were tried were surfaced in 
> some way.



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

[GitHub] tinkerpop issue #448: Python glv graphson update

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/448
  
Cool @aholmberg ... Here are some more pointers.


https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/GraphReader.java


https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/GraphWriter.java

Where `readObject/writeObject` are the genero methods.

Also, you might need to update `init-code-blocks.awk` so that the docs 
build.


https://github.com/apache/tinkerpop/blob/master/docs/preprocessor/awk/init-code-blocks.awk#L83

To test it -- `bin/process-docs.sh -f 
docs/src/reference/gremlin-variants.asciidoc`. If you can't test it easily, no 
worries. I will fiddle the `awk` and testing of doc building for you.


---
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-1496) Should a head-as("x") always be a select("x")?

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1496:
-

 Summary: Should a head-as("x") always be a select("x")?
 Key: TINKERPOP-1496
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1496
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.2
Reporter: Marko A. Rodriguez


There are two steps that treat a head of {{as("x")}} as {{select("x")}}. 

{code}
match(as("x").out().as("y"), ...) => match(select("x").out().as("y"), ...)
where(as("x").has("name")) => where(select("x").has("name"))
{code}

I don't like how these steps are "special" in this respect and I think that it 
would be elegant if a head-{{as()}} has a consistent meaning for all inner 
traversals.

Thus, I'm wondering if we should make it such that EVERY head {{as("x")}} gets 
translated to {{select("x")}}.

{code}
addE("knows").to(as("x").out("mother"))
property("name", as("x").out("mother").values("name"))
{code}

I believe this would be backwards compatible in the sense that there really 
isn't a reason why an inner traversal head-{{as()}} would be used to label. 
Dunno -- definitely need [~dkuppitz]/etc. feedback.



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

[jira] [Created] (TINKERPOP-1495) Global list deduplication doesn't work in OLAP

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-1495:
-

 Summary: Global list deduplication doesn't work in OLAP
 Key: TINKERPOP-1495
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1495
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.2
Reporter: Daniel Kuppitz
Assignee: Marko A. Rodriguez


{noformat}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> a = TinkerFactory.createModern().traversal().withComputer()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], graphcomputer]
gremlin> 
gremlin> 
g.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
==>[v[1],v[2],v[3],v[4],v[5],v[6]]
gremlin> 
a.V().as("a").repeat(both()).times(3).emit().as("b").group().by(select("a")).by(select("b").dedup().order().by(id).fold()).select(values).unfold().dedup()
==>[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[3],v[4],v[5],v[6]]
==>[v[1],v[2],v[3],v[4],v[6]]
==>[v[1],v[2],v[3],v[4],v[5]]
gremlin>
{noformat}

_Not tested in {{tp31}}._



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