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

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1356.
-
   Resolution: Fixed
 Assignee: Daniel Kuppitz
Fix Version/s: 3.2.3

This is no longer an issue in 3.2.3+. (perhaps we were already done with 
{{has}} in 3.2.2, I only verified that current versions do work as expected).

> 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: Daniel Kuppitz
> Fix For: 3.2.3
>
>
> {{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.15#6346)

[jira] [Commented] (TINKERPOP-1589) Re-Introduce CloseableIterator

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

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


> Re-Introduce CloseableIterator
> --
>
> Key: TINKERPOP-1589
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1589
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> In Blueprints, we used to have {{CloseableIterable}}, which allowed users to 
> release resources that might have been held by the underlying graph database. 
> We didn't port that interface to TinkerPop 3.x for some reason. Graphs like 
> OrientDB require a {{close()}} method for iterators returned from methods 
> like {{Graph.vertices()}} and {{Graph.edges()}}. In addition, allowing 
> {{close()}} from those iterators would make the {{close()}} on {{Traversal}} 
> (non-remote) more useful and meaningful (right now it is an empty method by 
> default). 
> In Blueprints, {{Graph.getVertices()}} and {{Graph.getEdges()}} returned a 
> {{Iterable}} and the Graph could choose to return {{CloseableIterator}}. 
> Users who wanted to write provider agnostic code would then have to do:
> {code}
> if (iterable instanceof CloseableIterable))
>   ((CloseableIterable) iterable).close();
> {code}
> I'm not sure why we didn't simply return {{CloseableIterable}} from those 
> methods. Any reason we shouldn't do that now? Perhaps the approach is to 
> introduce {{CloseableIterator}} to 3.2.4, but keep the return type of 
> {{edges/vertices()}} as {{Iterator}} and then for 3.3.0 change the return 
> type to {{CloseableIterator}}. In this way, the feature can be available in 
> next release of 3.2.4 without any API changes and users can do the 
> {{instanceof}} check above if they need to. Then for 3.3.0 when we allow API 
> changes we can just make it more convenient with a {{CloseableIterator}} 
> return type.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #548: TINKERPOP-1589 Re-introduced CloseableIterator

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/548
  
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-1589) Re-Introduce CloseableIterator

[ASF GitHub Bot (JIRA)]

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

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

Github user pauljackson commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98973022
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/FlatMapStep.java
 ---
@@ -44,6 +45,7 @@ public FlatMapStep(final Traversal.Admin traversal) {
 return this.head.split(this.iterator.next(), this);
 } else {
 this.head = this.starts.next();
+closeIterator();
--- End diff --

I'll update the PR.


> Re-Introduce CloseableIterator
> --
>
> Key: TINKERPOP-1589
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1589
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> In Blueprints, we used to have {{CloseableIterable}}, which allowed users to 
> release resources that might have been held by the underlying graph database. 
> We didn't port that interface to TinkerPop 3.x for some reason. Graphs like 
> OrientDB require a {{close()}} method for iterators returned from methods 
> like {{Graph.vertices()}} and {{Graph.edges()}}. In addition, allowing 
> {{close()}} from those iterators would make the {{close()}} on {{Traversal}} 
> (non-remote) more useful and meaningful (right now it is an empty method by 
> default). 
> In Blueprints, {{Graph.getVertices()}} and {{Graph.getEdges()}} returned a 
> {{Iterable}} and the Graph could choose to return {{CloseableIterator}}. 
> Users who wanted to write provider agnostic code would then have to do:
> {code}
> if (iterable instanceof CloseableIterable))
>   ((CloseableIterable) iterable).close();
> {code}
> I'm not sure why we didn't simply return {{CloseableIterable}} from those 
> methods. Any reason we shouldn't do that now? Perhaps the approach is to 
> introduce {{CloseableIterator}} to 3.2.4, but keep the return type of 
> {{edges/vertices()}} as {{Iterator}} and then for 3.3.0 change the return 
> type to {{CloseableIterator}}. In this way, the feature can be available in 
> next release of 3.2.4 without any API changes and users can do the 
> {{instanceof}} check above if they need to. Then for 3.3.0 when we allow API 
> changes we can just make it more convenient with a {{CloseableIterator}} 
> return type.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1589) Re-Introduce CloseableIterator

[ASF GitHub Bot (JIRA)]

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

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

Github user pauljackson commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98972948
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GraphStep.java
 ---
@@ -164,13 +164,13 @@ public int hashCode() {
 }
 
 /**
- * Attemps to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
+ * Attempts to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
  * to return this interface containing their vertices and edges if 
there are expensive resources that might need to
  * be released at some point.
  */
 @Override
 public void close() throws Exception {
-if (iterator != null && iterator instanceof CloseableIterator) {
--- End diff --

`GraphStep` doesn't extend `FlatMapStep`, so it doesn't have access to 
`closeIterator()`, but it can call `CloseableIterator.closeIterator(iterator)`


> Re-Introduce CloseableIterator
> --
>
> Key: TINKERPOP-1589
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1589
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> In Blueprints, we used to have {{CloseableIterable}}, which allowed users to 
> release resources that might have been held by the underlying graph database. 
> We didn't port that interface to TinkerPop 3.x for some reason. Graphs like 
> OrientDB require a {{close()}} method for iterators returned from methods 
> like {{Graph.vertices()}} and {{Graph.edges()}}. In addition, allowing 
> {{close()}} from those iterators would make the {{close()}} on {{Traversal}} 
> (non-remote) more useful and meaningful (right now it is an empty method by 
> default). 
> In Blueprints, {{Graph.getVertices()}} and {{Graph.getEdges()}} returned a 
> {{Iterable}} and the Graph could choose to return {{CloseableIterator}}. 
> Users who wanted to write provider agnostic code would then have to do:
> {code}
> if (iterable instanceof CloseableIterable))
>   ((CloseableIterable) iterable).close();
> {code}
> I'm not sure why we didn't simply return {{CloseableIterable}} from those 
> methods. Any reason we shouldn't do that now? Perhaps the approach is to 
> introduce {{CloseableIterator}} to 3.2.4, but keep the return type of 
> {{edges/vertices()}} as {{Iterator}} and then for 3.3.0 change the return 
> type to {{CloseableIterator}}. In this way, the feature can be available in 
> next release of 3.2.4 without any API changes and users can do the 
> {{instanceof}} check above if they need to. Then for 3.3.0 when we allow API 
> changes we can just make it more convenient with a {{CloseableIterator}} 
> return type.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #548: TINKERPOP-1589 Re-introduced CloseableIterator

[pauljackson]

Github user pauljackson commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98973022
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/FlatMapStep.java
 ---
@@ -44,6 +45,7 @@ public FlatMapStep(final Traversal.Admin traversal) {
 return this.head.split(this.iterator.next(), this);
 } else {
 this.head = this.starts.next();
+closeIterator();
--- End diff --

I'll update the PR.


---
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 #548: TINKERPOP-1589 Re-introduced CloseableIterator

[pauljackson]

Github user pauljackson commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98972948
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GraphStep.java
 ---
@@ -164,13 +164,13 @@ public int hashCode() {
 }
 
 /**
- * Attemps to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
+ * Attempts to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
  * to return this interface containing their vertices and edges if 
there are expensive resources that might need to
  * be released at some point.
  */
 @Override
 public void close() throws Exception {
-if (iterator != null && iterator instanceof CloseableIterator) {
--- End diff --

`GraphStep` doesn't extend `FlatMapStep`, so it doesn't have access to 
`closeIterator()`, but it can call `CloseableIterator.closeIterator(iterator)`


---
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: ChooseStep & count type coercion

[Ted Wilmes]

Thanks guys.  Ticket created:
https://issues.apache.org/jira/browse/TINKERPOP-1596

--Ted

On Wed, Feb 1, 2017 at 10:37 AM, Marko Rodriguez 
wrote:

> I concur with Robert.
>
> Kuppitz has done a lot to help in this area with NumberHelper. We should
> make sure it is propagated throughout.
> https://github.com/apache/tinkerpop/blob/master/gremlin-
> core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java <
> https://github.com/apache/tinkerpop/blob/master/gremlin-
> core/src/main/java/org/apache/tinkerpop/gremlin/util/NumberHelper.java>
>
> Can you please make a ticket about your particular ChooseStep situation?
>
> https://issues.apache.org/jira/browse/TINKERPOP/ <
> https://issues.apache.org/jira/browse/TINKERPOP/?
> selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel>
>
> Thank you,
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Feb 1, 2017, at 8:03 AM, Robert Dale  wrote:
> >
> > It absolutely would make sense to treat numbers as numbers and not as
> data
> > structures.  This is one of those things that keeps gremlin tied to a
> Java
> > implementation and from being language-agnostic.
> >
> > Robert Dale
> >
> > On Wed, Feb 1, 2017 at 9:51 AM, Ted Wilmes  wrote:
> >
> >> Hello,
> >> I wrote a traversal using a choose that included a count in the
> branching
> >> traversal.  Here is a simplified version:
> >>
> >> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> >> constant(3))
> >>
> >> I wasn't getting any results and then realized none of the options would
> >> match because count produces a long.
> >> This is the correct behavior now and makes sense in the context of
> Java's
> >> type system but I was wondering if it
> >> wouldn't make sense to handle the type coercion from int to long so the
> >> user could use an integer?  I think this
> >> would be consistent with how other steps like 'is' works:
> >>
> >> gremlin> g.V().local(bothE().count()).is(3)
> >> ==>3
> >> ==>3
> >> ==>3
> >>
> >>
> >> Full example:
> >> gremlin> g = TinkerFactory.createModern().traversal()
> >> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> >> gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3,
> >> constant(3))
> >> gremlin> g.V().choose(bothE().count()).option(1l,
> constant(1)).option(3l,
> >> constant(3))
> >> ==>3
> >> ==>1
> >> ==>3
> >> ==>3
> >> ==>1
> >> ==>1
> >>
> >>
> >> Thanks,
> >> Ted
> >>
>
>

[jira] [Created] (TINKERPOP-1620) Choose with count branch traversal type coercion

[Ted Wilmes (JIRA)]

Ted Wilmes created TINKERPOP-1620:
-

 Summary: Choose with count branch traversal type coercion
 Key: TINKERPOP-1620
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1620
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.3
Reporter: Ted Wilmes
Assignee: Ted Wilmes


A {{ChooseStep}} with a {{count}} branching traversal is currently sensitive to 
whether or not the {{option}} keys are {{long}} or {{int}}.  This results in 
the following behavior:

{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().choose(bothE().count()).option(1, constant(1)).option(3, 
constant(3))
gremlin> g.V().choose(bothE().count()).option(1l, constant(1)).option(3l, 
constant(3))
==>3
==>1
==>3
==>3
==>1
==>1
{code}

The branch traversal results if, numeric, should be evaluated against the 
options using {{NumberHelper}} so as to be consistent with other steps.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1572) Impossible to get DetachedVertex when Connecting via withRemote

[Marko A. Rodriguez (JIRA)]

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

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

Please see https://issues.apache.org/jira/browse/TINKERPOP-1592. If this is 
considered the better/more general model, then please close this ticket.

> Impossible to get DetachedVertex when Connecting via withRemote 
> 
>
> Key: TINKERPOP-1572
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1572
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.0-incubating, 3.2.3
>Reporter: Robert Dale
>Assignee: stephen mallette
>Priority: Minor
>
> Problem:
> Using gremlin-console:
> {noformat}
> gremlin> graph = EmptyGraph.instance()
> ==>emptygraph[empty]
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[emptygraph[empty], standard]
> gremlin> g.addV('foo').property('key','value')
> ==>v[0]
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
> {noformat}
> Works when is.testing=true
> {noformat}
> export JAVA_OPTIONS="-Dis.testing=true"
> # restart server
> # repeat above test, result is:
> gremlin> g.V().next().getClass()
> ==>class org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex
> {noformat}
> Appears to be a condition in 
> org.apache.tinkerpop.gremlin.server.util.TraverserIterator



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (TINKERPOP-1325) Query results with lambda step not serializable in OLAP

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1325.
-
Resolution: Duplicate
  Assignee: Marko A. Rodriguez

This problem is more general to the ability to serialize and deserialize 
lambdas. TINKERPOP-1569 addresses this. I am closing this as duplicate.

> Query results with lambda step not serializable in OLAP
> ---
>
> Key: TINKERPOP-1325
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1325
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop, server
>Affects Versions: 3.2.0-incubating
> Environment: OSX 10.11.5
> apache-gremlin-console-3.2.1
>Reporter: Sergey Gmyzov
>Assignee: Marko A. Rodriguez
>
> Query with lambda step fails in OLAP mode:
> {code}
> gremlin> :remote config alias g ds232.a
> ==>g=ds232.a
> gremlin> :> 
> schema.config().option('graph.traversal_sources.g.restrict_lambda').set(false);
> ==>null
> gremlin> :> 
> schema.config().option('graph.traversal_sources.a.restrict_lambda').set(false);
> ==>null
> gremlin> :> graph.tx().commit();
> ==>null
> gremlin> :> g.V().has("movieId","m267").map{it.get().value("title")};
> org.apache.spark.SparkException: Task not serializable
> Display stack trace? [yN] y
> org.apache.tinkerpop.gremlin.groovy.plugin.RemoteException: 
> org.apache.spark.SparkException: Task not serializable
>   at 
> org.apache.tinkerpop.gremlin.console.groovy.plugin.DriverRemoteAcceptor.submit(DriverRemoteAcceptor.java:156)
>   at 
> org.apache.tinkerpop.gremlin.console.commands.SubmitCommand.execute(SubmitCommand.groovy:41)
>   at org.codehaus.groovy.tools.shell.Shell.execute(Shell.groovy:104)
>   at 
> org.codehaus.groovy.tools.shell.Groovysh.super$2$execute(Groovysh.groovy)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
>   at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1212)
>   at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
>   at 
> org.codehaus.groovy.tools.shell.Groovysh.executeCommand(Groovysh.groovy:259)
>   at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:158)
>   at 
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
>   at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
>   at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1212)
>   at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
>   at 
> org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:63)
>   at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
>   at 
> org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
>   at 
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
>   at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1212)
>   at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
>   at 
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
>   at 
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
>   at 
> org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:59)
>   at 
> org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$run(InteractiveShellRunner.groovy)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> 

[jira] [Closed] (TINKERPOP-1315) HadoopConfiguration will not allow an ArrayList to be serialized in vertexProgram configuration unless setProperty is overriden

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1315.
-
Resolution: Won't Fix
  Assignee: Marko A. Rodriguez

Closing this as this is simply the semantics of Apache Commons and lists. 
Please reopen if you believe that TinkerPop should do something different.

> HadoopConfiguration will not allow an ArrayList to be serialized in 
> vertexProgram configuration unless setProperty is overriden
> ---
>
> Key: TINKERPOP-1315
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1315
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.1
>Reporter: Dylan Bethune-Waddell
>Assignee: Marko A. Rodriguez
>Priority: Minor
>
> I have been implementing a "PrecisionBulkLoader" class that takes a 
> ScriptTraversal with bindings that can execute against the target graph to 
> getOrCreate vertices/edges with more precision - this follows from my 
> realization that currently IncrementalBulkLoader will overwrite the first 
> edge of the same label in the target graph that is between the two vertex 
> endpoints - this is an issue for self-loops and multi-edges:
> https://issues.apache.org/jira/browse/TINKERPOP-1099
> I finally got it to work with the script bindings being propagated to 
> workers, but in order to do so without just taking the last value of the 
> Array I had to override the setProperty method in 
> org.apache.tinkerpop.gremlin.hadoop.structure.HadoopConfiguration - before I 
> did that, when ConfigurationUtils.copy(conf1, conf2) was called with a 
> HadoopConfiguration on either end (conf1 or conf2), any multi-valued / list 
> properties get clobbered and only the last value would be there after 
> storeState/loadState goes through the first cycle in BulkLoaderVertexProgram. 
> This is something that was bugging me for a while with multiple hosts 
> configured for TitanGraph in the config and the HadoopConf only opening a 
> connection against the last host in the list - this change to 
> HadoopConfiguration causes it to read  
> standardtitangraph[cassandrathrift:[host1, host2, ...]] in the spark executor 
> logs instead like you might expect, and allows the bindings for the 
> ScriptTraversal to survive storeState/loadState and be applied to the 
> traversal.
> I suppose I was wondering if this is dangerous or bad somehow? I know that in 
> a few places I saw the values of the configuration being explicitly 
> toString()'d...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (TINKERPOP-331) TraverserConverterStep (proposal)

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-331.

   Resolution: Won't Fix
Fix Version/s: (was: 3.2.4)

This is a cool idea, but I think the work [~twilmes] did with 
{{PathRetractionStrategy}} makes this ticket much less useful. Closing as as 
its no longer a valid optimization.

> TraverserConverterStep (proposal)
> -
>
> Key: TINKERPOP-331
> URL: https://issues.apache.org/jira/browse/TINKERPOP-331
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Different {{Traverser}} implementations have different memory requirements 
> and "bulkability." Once the memory of a {{Traverser}} is no longer needed, 
> then it should be converted to a simpler form.
> {code}
> g.V.as('x').out.jump('x',3).simplePath.out('knows').age.groupCount
> |__||_|
> PathTraverser  SimpleTraverser
> {code}
> A {{TraverserConverterStrategy}} should insert a {{TraverserConverterStep}} 
> after {{simplePath()}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1528) CountByIsRangeStrategy fails for a particular query

[Marko A. Rodriguez (JIRA)]

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

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

I just verified that this problem still exists in the {{tp32/}} line.

{code}
gremlin> g.V().count().is(0)
gremlin> g.V().count().is(0).explain()
==>Traversal Explanation
=
Original Traversal [GraphStep(vertex,[]), CountGlobalStep, 
IsStep(eq(0))]

ConnectiveStrategy   [D]   [GraphStep(vertex,[]), CountGlobalStep, 
IsStep(eq(0))]
RangeByIsCountStrategy   [O]   [NotStep([GraphStep(vertex,[])])]
...
{code}

> CountByIsRangeStrategy fails for a particular query
> ---
>
> Key: TINKERPOP-1528
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1528
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>
> In a fresh TinkerGraph:
> {noformat}
> gremlin> g.V().count()
> ==>0
> gremlin> g.V().count().is(0)
> gremlin>
> {noformat}
> Because of {{.is(0)}} the traversal is converted to something like 
> {{g.not(V())}}. No issues with other values (!= 0).
> {noformat}
> gremlin> g.addV()
> ==>v[0]
> gremlin> g.V().count()
> ==>1
> gremlin> g.V().count().is(0)
> gremlin> g.V().count().is(1)
> ==>1
> gremlin> g.V().count().is(2)
> gremlin>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (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:comment-tabpanel=15848658#comment-15848658
 ] 

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

I know we did a lot of work with arrays and {{has()}}. Thus, is this still an 
issue? If not, please close it.

> 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.15#6346)

[jira] [Closed] (TINKERPOP-1243) MatchStep should be a FilterStep, not a MapStep

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1243.
-
Resolution: Invalid
  Assignee: Marko A. Rodriguez

This is a nice idea, but the problem, {{MatchStep}} is actually a 
{{FlatMapStep}} as it "flatmaps out" pattern matches given the input. If we are 
going to do anything in the spirit of this ticket, it should be that the input 
is returned, NOT a {{Map}} (that is what {{select()}} is for). I 
will close this ticket as invalid and if we wish later on, we can remove the 
{{Map}} mapping in another ticket.

> MatchStep should be a FilterStep, not a MapStep
> ---
>
> Key: TINKERPOP-1243
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1243
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.1-incubating, 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
>
> {{MatchStep}} should really be a {{FilterStep}}. It simply filters out all 
> traversers that don't match the patterns. However, given that you typically 
> {{select()}} after {{match()}}, a {{Map}} is generated. The 
> benefit of making it a {{FilterStep}} is that people can use {{match()}} to 
> filter without having to deal with unrolling the {{Map}}. Moreover, it feels 
> more consistent with the language constructs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (TINKERPOP-1208) Support for MessageScope.Subgraph in GraphComputer

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez closed TINKERPOP-1208.
-
Resolution: Duplicate
  Assignee: Marko A. Rodriguez

This is being handled by the {{Partition}}/{{Partitioner}} ticket. 
TINKERPOP-1564. Thus, closing this duplicate.

> Support for MessageScope.Subgraph in GraphComputer
> --
>
> Key: TINKERPOP-1208
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1208
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> I don't really know the best way to express this, but I think we should allow 
> a {{VertexProgram}} to state which vertices it should process at each 
> iteration. For most {{VertexProgram}}s only those vertices that received a 
> message in the last iteration need to be evaluated. What is the best way to 
> say this so that {{GraphComputer}} implementations can use it, I don't know. 
> This is all really related to {{GraphFilter}} and {{MessageScope}} as well. 
> Basically, at every iteration, what subgraph do you need to grab to process? 
> ... we should really tie all those concepts together nicely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1589) Re-Introduce CloseableIterator

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98930854
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/FlatMapStep.java
 ---
@@ -44,6 +45,7 @@ public FlatMapStep(final Traversal.Admin traversal) {
 return this.head.split(this.iterator.next(), this);
 } else {
 this.head = this.starts.next();
+closeIterator();
--- End diff --

This should go before `this.starts.next()` as if `this.starts.next()` is 
empty, it will throw `FastNoSuchElementException` and the previous iterator 
would not have been closed.


> Re-Introduce CloseableIterator
> --
>
> Key: TINKERPOP-1589
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1589
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> In Blueprints, we used to have {{CloseableIterable}}, which allowed users to 
> release resources that might have been held by the underlying graph database. 
> We didn't port that interface to TinkerPop 3.x for some reason. Graphs like 
> OrientDB require a {{close()}} method for iterators returned from methods 
> like {{Graph.vertices()}} and {{Graph.edges()}}. In addition, allowing 
> {{close()}} from those iterators would make the {{close()}} on {{Traversal}} 
> (non-remote) more useful and meaningful (right now it is an empty method by 
> default). 
> In Blueprints, {{Graph.getVertices()}} and {{Graph.getEdges()}} returned a 
> {{Iterable}} and the Graph could choose to return {{CloseableIterator}}. 
> Users who wanted to write provider agnostic code would then have to do:
> {code}
> if (iterable instanceof CloseableIterable))
>   ((CloseableIterable) iterable).close();
> {code}
> I'm not sure why we didn't simply return {{CloseableIterable}} from those 
> methods. Any reason we shouldn't do that now? Perhaps the approach is to 
> introduce {{CloseableIterator}} to 3.2.4, but keep the return type of 
> {{edges/vertices()}} as {{Iterator}} and then for 3.3.0 change the return 
> type to {{CloseableIterator}}. In this way, the feature can be available in 
> next release of 3.2.4 without any API changes and users can do the 
> {{instanceof}} check above if they need to. Then for 3.3.0 when we allow API 
> changes we can just make it more convenient with a {{CloseableIterator}} 
> return type.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1589) Re-Introduce CloseableIterator

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98931140
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GraphStep.java
 ---
@@ -164,13 +164,13 @@ public int hashCode() {
 }
 
 /**
- * Attemps to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
+ * Attempts to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
  * to return this interface containing their vertices and edges if 
there are expensive resources that might need to
  * be released at some point.
  */
 @Override
 public void close() throws Exception {
-if (iterator != null && iterator instanceof CloseableIterator) {
--- End diff --

Why doesn't `GraphStep` implement `AutoCloseable` like the others?


> Re-Introduce CloseableIterator
> --
>
> Key: TINKERPOP-1589
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1589
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> In Blueprints, we used to have {{CloseableIterable}}, which allowed users to 
> release resources that might have been held by the underlying graph database. 
> We didn't port that interface to TinkerPop 3.x for some reason. Graphs like 
> OrientDB require a {{close()}} method for iterators returned from methods 
> like {{Graph.vertices()}} and {{Graph.edges()}}. In addition, allowing 
> {{close()}} from those iterators would make the {{close()}} on {{Traversal}} 
> (non-remote) more useful and meaningful (right now it is an empty method by 
> default). 
> In Blueprints, {{Graph.getVertices()}} and {{Graph.getEdges()}} returned a 
> {{Iterable}} and the Graph could choose to return {{CloseableIterator}}. 
> Users who wanted to write provider agnostic code would then have to do:
> {code}
> if (iterable instanceof CloseableIterable))
>   ((CloseableIterable) iterable).close();
> {code}
> I'm not sure why we didn't simply return {{CloseableIterable}} from those 
> methods. Any reason we shouldn't do that now? Perhaps the approach is to 
> introduce {{CloseableIterator}} to 3.2.4, but keep the return type of 
> {{edges/vertices()}} as {{Iterator}} and then for 3.3.0 change the return 
> type to {{CloseableIterator}}. In this way, the feature can be available in 
> next release of 3.2.4 without any API changes and users can do the 
> {{instanceof}} check above if they need to. Then for 3.3.0 when we allow API 
> changes we can just make it more convenient with a {{CloseableIterator}} 
> return type.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #548: TINKERPOP-1589 Re-introduced CloseableIterator

[okram]

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98931140
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GraphStep.java
 ---
@@ -164,13 +164,13 @@ public int hashCode() {
 }
 
 /**
- * Attemps to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
+ * Attempts to close an underlying iterator if it is of type {@link 
CloseableIterator}. Graph providers may choose
  * to return this interface containing their vertices and edges if 
there are expensive resources that might need to
  * be released at some point.
  */
 @Override
 public void close() throws Exception {
-if (iterator != null && iterator instanceof CloseableIterator) {
--- End diff --

Why doesn't `GraphStep` implement `AutoCloseable` like the others?


---
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 #548: TINKERPOP-1589 Re-introduced CloseableIterator

[okram]

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/548#discussion_r98930854
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/FlatMapStep.java
 ---
@@ -44,6 +45,7 @@ public FlatMapStep(final Traversal.Admin traversal) {
 return this.head.split(this.iterator.next(), this);
 } else {
 this.head = this.starts.next();
+closeIterator();
--- End diff --

This should go before `this.starts.next()` as if `this.starts.next()` is 
empty, it will throw `FastNoSuchElementException` and the previous iterator 
would not have been closed.


---
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-1044) ResponseMessage should contain server-side exception name.

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1044:
-

This one remains open at the pull request related to this change only added a 
change for REST. There is a larger body of work related to the gremlin server 
protocol and the error responses.

> ResponseMessage should contain server-side exception name.
> --
>
> Key: TINKERPOP-1044
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1044
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.0-incubating
>Reporter: Bob Briody
>Priority: Minor
>
> When an exception occurs during execution by gremlin server, the 
> ResponseMessage currently contains the Exception message, but it would also 
> be helpful to include the Exception class name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)