[jira] [Closed] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-1919.
---
Resolution: Fixed
> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both
> classes or we could also just merge those two classes together. I think the
> reason why they are split was simply that the methods in
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely
> generated and I didn't want to write much code inside of Groovy strings that
> were part of the {{pom.xml}} before [~spmallette] introduced templates for
> the GLV generation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397802#comment-16397802
]
ASF GitHub Bot commented on TINKERPOP-1919:
---
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/816
> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both
> classes or we could also just merge those two classes together. I think the
> reason why they are split was simply that the methods in
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely
> generated and I didn't want to write much code inside of Groovy strings that
> were part of the {{pom.xml}} before [~spmallette] introduced templates for
> the GLV generation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #816: TINKERPOP-1919 Merge classes P and TraversalPre...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/816 ---
[jira] [Updated] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Weber updated TINKERPOP-1924:
Description:
I'm currently running into a situation where I'd like to access meta-properties
through the values(...)-method. Unfortunately, the signature of values() only
takes strings, so this is not possible:
{code:java}
g.V().values(T.id)
{code}
Of course, there's the trivial workaround:
{code:java}
g.V().id()
{code}
However, I'd like to get values for multiple properties, so the workaround
becomes ugly:
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
That there would be no overload of values(...) supporting T-accessors is a bit
odd. has(...) has an extra overload for T-accessors, property(...) allows
arbitrary objects to be passed in as key. The valueMap-method allows including
T-accessors in the returned map.
Would it be possible to relax the signature of values(...) to take an arbitraty
list of objects instead of property keys of type string? If the discussion here
turns out in favor of such a relaxation, I could try to implement the change.
was:
I'm currently running into a situation where I'd like to access meta-properties
through the values(...)-method. Unfortunately, the signature of values() only
takes strings, so this is not possible:
{code:java}
g.V().values(T.id)
{code}
Of course, there's the trivial workaround:
{code:java}
g.V().id()
{code}
However, I'd like to get values for multiple properties, so the workaround
becomes ugly:
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
That there would be no overload of 'values' supporting T-accessors is a bit
odd. has(...) has an extra overload for T-accessors, property(...) allows
arbitrary objects to be passed in as key. The valueMap-method allows including
T-accessors in the returned map.
Would it be possible to relax the signature of values(...) to take an arbitraty
list of objects instead of property keys of type string? If the discussion here
turns out in favor of such a relaxation, I could try to implement the change.
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitraty list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Weber updated TINKERPOP-1924:
Description:
I'm currently running into a situation where I'd like to access meta-properties
through the values(...)-method. Unfortunately, the signature of values() only
takes strings, so this is not possible:
{code:java}
g.V().values(T.id)
{code}
Of course, there's the trivial workaround:
{code:java}
g.V().id()
{code}
However, I'd like to get values for multiple properties, so the workaround
becomes ugly:
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
That there would be no overload of values(...) supporting T-accessors is a bit
odd. has(...) has an extra overload for T-accessors, property(...) allows
arbitrary objects to be passed in as key. The valueMap-method allows including
T-accessors in the returned map.
Would it be possible to relax the signature of values(...) to take an arbitrary
list of objects instead of property keys of type string? If the discussion here
turns out in favor of such a relaxation, I could try to implement the change.
was:
I'm currently running into a situation where I'd like to access meta-properties
through the values(...)-method. Unfortunately, the signature of values() only
takes strings, so this is not possible:
{code:java}
g.V().values(T.id)
{code}
Of course, there's the trivial workaround:
{code:java}
g.V().id()
{code}
However, I'd like to get values for multiple properties, so the workaround
becomes ugly:
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
That there would be no overload of values(...) supporting T-accessors is a bit
odd. has(...) has an extra overload for T-accessors, property(...) allows
arbitrary objects to be passed in as key. The valueMap-method allows including
T-accessors in the returned map.
Would it be possible to relax the signature of values(...) to take an arbitraty
list of objects instead of property keys of type string? If the discussion here
turns out in favor of such a relaxation, I could try to implement the change.
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of values(...) supporting T-accessors is a
> bit odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitrary list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
[
https://issues.apache.org/jira/browse/TINKERPOP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Weber updated TINKERPOP-1924:
Description:
I'm currently running into a situation where I'd like to access meta-properties
through the values(...)-method. Unfortunately, the signature of values() only
takes strings, so this is not possible:
{code:java}
g.V().values(T.id)
{code}
Of course, there's the trivial workaround:
{code:java}
g.V().id()
{code}
However, I'd like to get values for multiple properties, so the workaround
becomes ugly:
{code:java}
g.V().union(__.id(), __.values('key'))
{code}
That there would be no overload of 'values' supporting T-accessors is a bit
odd. has(...) has an extra overload for T-accessors, property(...) allows
arbitrary objects to be passed in as key. The valueMap-method allows including
T-accessors in the returned map.
Would it be possible to relax the signature of values(...) to take an arbitraty
list of objects instead of property keys of type string? If the discussion here
turns out in favor of such a relaxation, I could try to implement the change.
was:
I'm currently running into a situation where I'd like to access meta-properties
through the values(...)-method. Unfortunately, the signature of values() only
takes strings, so this is not possible:
{code:java}
g.V().values(T.id)
{code}
Of course, there's the trivial workaround:
{code:java}
g.V().id()
{code}
However, I'd like to get values for multiple properties, so the workaround
becomes ugly:
{code:java}
// g.V().union(__.id(), __.values('key'))
{code}
That there would be no overload of 'values' supporting T-accessors is a bit
odd. has(...) has an extra overload for T-accessors, property(...) allows
arbitrary objects to be passed in as key. The valueMap-method allows including
T-accessors in the returned map.
Would it be possible to relax the signature of values(...) to take an arbitraty
list of objects instead of property keys of type string? If the discussion here
turns out in favor of such a relaxation, I could try to implement the change.
> Make meta-properties accessible via values(...)-step
>
>
> Key: TINKERPOP-1924
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.3.1
>Reporter: Daniel Weber
>Priority: Minor
>
> I'm currently running into a situation where I'd like to access
> meta-properties through the values(...)-method. Unfortunately, the signature
> of values() only takes strings, so this is not possible:
> {code:java}
> g.V().values(T.id)
> {code}
> Of course, there's the trivial workaround:
> {code:java}
> g.V().id()
> {code}
> However, I'd like to get values for multiple properties, so the workaround
> becomes ugly:
> {code:java}
> g.V().union(__.id(), __.values('key'))
> {code}
> That there would be no overload of 'values' supporting T-accessors is a bit
> odd. has(...) has an extra overload for T-accessors, property(...) allows
> arbitrary objects to be passed in as key. The valueMap-method allows
> including T-accessors in the returned map.
> Would it be possible to relax the signature of values(...) to take an
> arbitraty list of objects instead of property keys of type string? If the
> discussion here turns out in favor of such a relaxation, I could try to
> implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1924) Make meta-properties accessible via values(...)-step
Daniel Weber created TINKERPOP-1924:
---
Summary: Make meta-properties accessible via values(...)-step
Key: TINKERPOP-1924
URL: https://issues.apache.org/jira/browse/TINKERPOP-1924
Project: TinkerPop
Issue Type: Improvement
Components: structure
Affects Versions: 3.3.1
Reporter: Daniel Weber
I'm currently running into a situation where I'd like to access meta-properties
through the values(...)-method. Unfortunately, the signature of values() only
takes strings, so this is not possible:
{code:java}
g.V().values(T.id)
{code}
Of course, there's the trivial workaround:
{code:java}
g.V().id()
{code}
However, I'd like to get values for multiple properties, so the workaround
becomes ugly:
{code:java}
// g.V().union(__.id(), __.values('key'))
{code}
That there would be no overload of 'values' supporting T-accessors is a bit
odd. has(...) has an extra overload for T-accessors, property(...) allows
arbitrary objects to be passed in as key. The valueMap-method allows including
T-accessors in the returned map.
Would it be possible to relax the signature of values(...) to take an arbitraty
list of objects instead of property keys of type string? If the discussion here
turns out in favor of such a relaxation, I could try to implement the change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1901) Enable usage of enums in more steps in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-1901.
---
Resolution: Fixed
> Enable usage of enums in more steps in Gremlin.Net
> --
>
> Key: TINKERPOP-1901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1901
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> Java enums can implement interfaces and some Gremlin steps take interfaces as
> arguments that are implemented by enums like {{T}} or {{P}} in Java. However,
> C# enums can't have any methods and therefore also not implement interfaces.
> For this reason, step arguments whose type is one of those interfaces
> ({{Predicate}}, {{Function}}, ...) currently have the type {{object}} in
> Gremlin.Net which makes it hard for users to know what kind of values they
> can use for these arguments.
> This overload of the {{By}} step is a good example for this:
> * In Gremlin-java:
> {code:java}
> public default GraphTraversal by(final Traversal traversal,
> final Comparator comparator)
> {code}
> * In Gremlin.Net:
> {code}
> public GraphTraversal By (object function, object comparator)
> {code}
> [~jorgebg] [suggested two possible
> solutions|https://github.com/apache/tinkerpop/pull/792#discussion_r167847541]
> for this problem:
> {quote} * Use a class for T (not an enum), properties like T.Id could return
> instances of whatever interface we create for it. Given that java enums
> functionality is more comprehensive than what C# currently supports, it makes
> sense to use a class IMO.
> * Generate the offending traversal methods manually.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1901) Enable usage of enums in more steps in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397608#comment-16397608
]
ASF GitHub Bot commented on TINKERPOP-1901:
---
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/815
> Enable usage of enums in more steps in Gremlin.Net
> --
>
> Key: TINKERPOP-1901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1901
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> Java enums can implement interfaces and some Gremlin steps take interfaces as
> arguments that are implemented by enums like {{T}} or {{P}} in Java. However,
> C# enums can't have any methods and therefore also not implement interfaces.
> For this reason, step arguments whose type is one of those interfaces
> ({{Predicate}}, {{Function}}, ...) currently have the type {{object}} in
> Gremlin.Net which makes it hard for users to know what kind of values they
> can use for these arguments.
> This overload of the {{By}} step is a good example for this:
> * In Gremlin-java:
> {code:java}
> public default GraphTraversal by(final Traversal traversal,
> final Comparator comparator)
> {code}
> * In Gremlin.Net:
> {code}
> public GraphTraversal By (object function, object comparator)
> {code}
> [~jorgebg] [suggested two possible
> solutions|https://github.com/apache/tinkerpop/pull/792#discussion_r167847541]
> for this problem:
> {quote} * Use a class for T (not an enum), properties like T.Id could return
> instances of whatever interface we create for it. Given that java enums
> functionality is more comprehensive than what C# currently supports, it makes
> sense to use a class IMO.
> * Generate the offending traversal methods manually.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #815: TINKERPOP-1901 Transform enums into classes in ...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/815 ---
[DISCUSS] Drop support for Giraph in 3.4.0
A week or so ago I decided to try to figure out what was going on with the Giraph upgrade - some of you may recall that we backed off doing that upgrade for 3.3.0 at the last minute because it was hanging up Hadoop. After messing with it for a bit, I started to wonder why this work was necessary at all. Why not just suggest to the community that we drop support for Giraph in 3.4.0? Some reasoning: 1. This weird Hadoop hanging problem is preventing upgrade. I suppose I could try to figure it out, but Marko already tried and didn't succeed, so I'm not sure what new insight I would bring since he was the expert. 2. It massively slows our integration tests. we could be many times more productive without giraph in the build. 3. The Giraph community seems dormant (not one post on user mailing list since November 2017 and very little happening on dev though i just learned they have an LGPL dependency in their stuff while looking at recent posts - no one has jumped on it to address it - the PR from community is still open https://github.com/apache/giraph/pull/61 and over 2 weeks old). It just doesn't seem like anyone is really maintaining or advancing the project. 4. I could be wrong, but I sense that most organizations are using gremlin-spark to do their work and giraph is largely unused. Anyway, it would be good to hear any feedback on this fairly major decision. If there are no objections here on the dev list, I will take this discussion to the user list and twitter to see if what the user community thinks. Thanks, stephen
[jira] [Issue Comment Deleted] (TINKERPOP-1923) Intermittent NegativeArraySizeException on drop
[
https://issues.apache.org/jira/browse/TINKERPOP-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Baker updated TINKERPOP-1923:
---
Comment: was deleted
(was: Looking in the logs, it seems to be printing the "Removing original
vertices" message twice (it shouldn't, there is nothing in the code that should
cause that to happen) - so that could be some strange compiler bug. Presumably
if the log message is being called twice, the drop command could be called
twice too.
If the Gremlin query was called twice, would you expect to see the error above?)
> Intermittent NegativeArraySizeException on drop
> ---
>
> Key: TINKERPOP-1923
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1923
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.3.1
>Reporter: James Baker
>Priority: Major
>
> I am intermittently getting the following exception when dropping vertices on
> a TinkerGraph:
> {noformat}
> Exception in thread "main" java.lang.NegativeArraySizeException
> at java.util.AbstractCollection.toArray(AbstractCollection.java:136)
> at java.util.ArrayList.addAll(ArrayList.java:581)
> at java.util.HashMap$Values.forEach(HashMap.java:981)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerHelper.getEdges(TinkerHelper.java:172)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.edges(TinkerVertex.java:146)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.remove(TinkerVertex.java:131)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.DropStep.filter(DropStep.java:67)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.iterate(Traversal.java:203)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.iterate(GraphTraversal.java:2664)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal$Admin.iterate(GraphTraversal.java:177)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.DefaultGraphTraversal.iterate(DefaultGraphTraversal.java:48)
> at mycode.merge.GraphMerger.mergeVertices(GraphMerger.java:172)
> at mycode.merge.GraphMerger.lambda$mergeGraphs$6(GraphMerger.java:78)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at mycode.merge.GraphMerger.mergeGraphs(GraphMerger.java:79)
> at mycode.cli.mapper.MergeGraphFiles.main(MergeGraphFiles.java:117)
> {noformat}
> My code is as follows (the last line is Line 172, which is where the
> exception is thrown):
> {code:java}
> LOGGER.info("Removing original vertices");
> Object[] ids = mergeGroup.stream().map(Element::id).toArray();
> LOGGER.debug("IDs to remove {}", ids);
> if(ids != null && ids.length > 0)
> graph.traversal().V(ids).drop().iterate();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-1923) Intermittent NegativeArraySizeException on drop
[
https://issues.apache.org/jira/browse/TINKERPOP-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397105#comment-16397105
]
James Baker edited comment on TINKERPOP-1923 at 3/13/18 3:33 PM:
-
Looking in the logs, it seems to be printing the "Removing original vertices"
message twice (it shouldn't, there is nothing in the code that should cause
that to happen) - so that could be some strange compiler bug. Presumably if the
log message is being called twice, the drop command could be called twice too.
If the Gremlin query was called twice, would you expect to see the error above?
was (Author: james.d.baker):
So this might be a combination of a Java 9 and TinkerGraph problem. If I
compile with Java 8, it seems more robust.
Looking in the logs, it seems to be printing the "Removing original vertices"
message twice (it shouldn't, there is nothing in the code that should cause
that to happen) - so that could be some strange Java 9 compiler bug. Presumably
if the log message is being called twice, the drop command could be called
twice too.
If the Gremlin query was called twice, would you expect to see the error above?
> Intermittent NegativeArraySizeException on drop
> ---
>
> Key: TINKERPOP-1923
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1923
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.3.1
>Reporter: James Baker
>Priority: Major
>
> I am intermittently getting the following exception when dropping vertices on
> a TinkerGraph:
> {noformat}
> Exception in thread "main" java.lang.NegativeArraySizeException
> at java.util.AbstractCollection.toArray(AbstractCollection.java:136)
> at java.util.ArrayList.addAll(ArrayList.java:581)
> at java.util.HashMap$Values.forEach(HashMap.java:981)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerHelper.getEdges(TinkerHelper.java:172)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.edges(TinkerVertex.java:146)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.remove(TinkerVertex.java:131)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.DropStep.filter(DropStep.java:67)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.iterate(Traversal.java:203)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.iterate(GraphTraversal.java:2664)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal$Admin.iterate(GraphTraversal.java:177)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.DefaultGraphTraversal.iterate(DefaultGraphTraversal.java:48)
> at mycode.merge.GraphMerger.mergeVertices(GraphMerger.java:172)
> at mycode.merge.GraphMerger.lambda$mergeGraphs$6(GraphMerger.java:78)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at mycode.merge.GraphMerger.mergeGraphs(GraphMerger.java:79)
> at mycode.cli.mapper.MergeGraphFiles.main(MergeGraphFiles.java:117)
> {noformat}
> My code is as follows (the last line is Line 172, which is where the
> exception is thrown):
> {code:java}
> LOGGER.info("Removing original vertices");
> Object[] ids = mergeGroup.stream().map(Element::id).toArray();
> LOGGER.debug("IDs to remove {}", ids);
> if(ids != null && ids.length > 0)
> graph.traversal().V(ids).drop().iterate();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1923) Intermittent NegativeArraySizeException on drop
[
https://issues.apache.org/jira/browse/TINKERPOP-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397105#comment-16397105
]
James Baker commented on TINKERPOP-1923:
So this might be a combination of a Java 9 and TinkerGraph problem. If I
compile with Java 8, it seems more robust.
Looking in the logs, it seems to be printing the "Removing original vertices"
message twice (it shouldn't, there is nothing in the code that should cause
that to happen) - so that could be some strange Java 9 compiler bug. Presumably
if the log message is being called twice, the drop command could be called
twice too.
If the Gremlin query was called twice, would you expect to see the error above?
> Intermittent NegativeArraySizeException on drop
> ---
>
> Key: TINKERPOP-1923
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1923
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.3.1
>Reporter: James Baker
>Priority: Major
>
> I am intermittently getting the following exception when dropping vertices on
> a TinkerGraph:
> {noformat}
> Exception in thread "main" java.lang.NegativeArraySizeException
> at java.util.AbstractCollection.toArray(AbstractCollection.java:136)
> at java.util.ArrayList.addAll(ArrayList.java:581)
> at java.util.HashMap$Values.forEach(HashMap.java:981)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerHelper.getEdges(TinkerHelper.java:172)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.edges(TinkerVertex.java:146)
> at
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.remove(TinkerVertex.java:131)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.DropStep.filter(DropStep.java:67)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
> at
> org.apache.tinkerpop.gremlin.process.traversal.Traversal.iterate(Traversal.java:203)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.iterate(GraphTraversal.java:2664)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal$Admin.iterate(GraphTraversal.java:177)
> at
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.DefaultGraphTraversal.iterate(DefaultGraphTraversal.java:48)
> at mycode.merge.GraphMerger.mergeVertices(GraphMerger.java:172)
> at mycode.merge.GraphMerger.lambda$mergeGraphs$6(GraphMerger.java:78)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at mycode.merge.GraphMerger.mergeGraphs(GraphMerger.java:79)
> at mycode.cli.mapper.MergeGraphFiles.main(MergeGraphFiles.java:117)
> {noformat}
> My code is as follows (the last line is Line 172, which is where the
> exception is thrown):
> {code:java}
> LOGGER.info("Removing original vertices");
> Object[] ids = mergeGroup.stream().map(Element::id).toArray();
> LOGGER.debug("IDs to remove {}", ids);
> if(ids != null && ids.length > 0)
> graph.traversal().V(ids).drop().iterate();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs
[ https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397088#comment-16397088 ] ASF GitHub Bot commented on TINKERPOP-1861: --- Github user PBGraff commented on the issue: https://github.com/apache/tinkerpop/pull/772 @spmallette Thanks for the heads-up, but I don't think I'll have a chance to get to it before then. It isn't so urgent it can't wait for the next release as it's code style as opposed to a bug. > VertexProgram create with varargs for Graphs > > > Key: TINKERPOP-1861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1861 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.7 >Reporter: Philip Graff >Priority: Minor > > VertexProgram.Builder.create(Graph) can be modified to > VertexProgram.Builder.create(Graph...) so that passing in zero or many graphs > is naturally handled. The current state of passing in null when no graph is > needed is bad practice. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #772: TINKERPOP-1861 Modify VertexProgram Builder to take va...
Github user PBGraff commented on the issue: https://github.com/apache/tinkerpop/pull/772 @spmallette Thanks for the heads-up, but I don't think I'll have a chance to get to it before then. It isn't so urgent it can't wait for the next release as it's code style as opposed to a bug. ---
[jira] [Created] (TINKERPOP-1923) Intermittent NegativeArraySizeException on drop
James Baker created TINKERPOP-1923:
--
Summary: Intermittent NegativeArraySizeException on drop
Key: TINKERPOP-1923
URL: https://issues.apache.org/jira/browse/TINKERPOP-1923
Project: TinkerPop
Issue Type: Bug
Components: tinkergraph
Affects Versions: 3.3.1
Reporter: James Baker
I am intermittently getting the following exception when dropping vertices on a
TinkerGraph:
{noformat}
Exception in thread "main" java.lang.NegativeArraySizeException
at java.util.AbstractCollection.toArray(AbstractCollection.java:136)
at java.util.ArrayList.addAll(ArrayList.java:581)
at java.util.HashMap$Values.forEach(HashMap.java:981)
at
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerHelper.getEdges(TinkerHelper.java:172)
at
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.edges(TinkerVertex.java:146)
at
org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerVertex.remove(TinkerVertex.java:131)
at
org.apache.tinkerpop.gremlin.process.traversal.step.filter.DropStep.filter(DropStep.java:67)
at
org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:38)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
at
org.apache.tinkerpop.gremlin.process.traversal.step.filter.FilterStep.processNextStart(FilterStep.java:37)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:128)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:38)
at
org.apache.tinkerpop.gremlin.process.traversal.Traversal.iterate(Traversal.java:203)
at
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.iterate(GraphTraversal.java:2664)
at
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal$Admin.iterate(GraphTraversal.java:177)
at
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.DefaultGraphTraversal.iterate(DefaultGraphTraversal.java:48)
at mycode.merge.GraphMerger.mergeVertices(GraphMerger.java:172)
at mycode.merge.GraphMerger.lambda$mergeGraphs$6(GraphMerger.java:78)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at
java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3566)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at mycode.merge.GraphMerger.mergeGraphs(GraphMerger.java:79)
at mycode.cli.mapper.MergeGraphFiles.main(MergeGraphFiles.java:117)
{noformat}
My code is as follows (the last line is Line 172, which is where the exception
is thrown):
{code:java}
LOGGER.info("Removing original vertices");
Object[] ids = mergeGroup.stream().map(Element::id).toArray();
LOGGER.debug("IDs to remove {}", ids);
if(ids != null && ids.length > 0)
graph.traversal().V(ids).drop().iterate();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1896) gremlin-python lambdas error
[
https://issues.apache.org/jira/browse/TINKERPOP-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397076#comment-16397076
]
ASF GitHub Bot commented on TINKERPOP-1896:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/814
VOTE: +1
> gremlin-python lambdas error
>
>
> Key: TINKERPOP-1896
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1896
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.3.1
>Reporter: Branden Moore
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin-python lambdas throw an error on the server when the preceding step
> produces maps.
> {code}
> Traceback (most recent call last):
> File "foo.py", line 15, in
> print g.V().has('name').match(__.as_('x').label().as_('lbl'),
> __.as_('x').id().as_('id')).select('lbl', 'id').map(lambda: "lambda x:
> type(x)").toList()
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 52, in toList
> return list(iter(self))
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 70, in next
> return self.__next__()
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 43, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 352, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/remote_connection.py",
> line 143, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/driver_remote_connection.py",
> line 54, in submit
> results = result_set.all().result()
> File
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line
> 462, in result
> return self.__get_result()
> File
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line
> 414, in __get_result
> raise exception_type, self._exception, self._traceback
> gremlin_python.driver.protocol.GremlinServerError: 599: AttributeError: type
> object 'org.apache.tinkerpop.gremlin.process.traversal.dsl' has no attribute
> 'as_' in
[GitHub] tinkerpop issue #814: TINKERPOP-1896 Fixed bug in lambda processing for pyth...
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/814 VOTE: +1 ---
[jira] [Commented] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396864#comment-16396864
]
ASF GitHub Bot commented on TINKERPOP-1919:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/816
> Although it will probably just concentrate on cases where users already
implemented their own predicates as there should be no visible changes for
users that only used our predicates
exactly - VOTE +1
> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both
> classes or we could also just merge those two classes together. I think the
> reason why they are split was simply that the methods in
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely
> generated and I didn't want to write much code inside of Groovy strings that
> were part of the {{pom.xml}} before [~spmallette] introduced templates for
> the GLV generation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #816: TINKERPOP-1919 Merge classes P and TraversalPredicate ...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/816 > Although it will probably just concentrate on cases where users already implemented their own predicates as there should be no visible changes for users that only used our predicates exactly - VOTE +1 ---
[jira] [Commented] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396859#comment-16396859
]
ASF GitHub Bot commented on TINKERPOP-1919:
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/816
>I think this is a good change though it doesn't exactly mimic the Java API
right? there is no until(P) in java - it's until(Predicate), but I guess that
doesn't really make sense in this GLV to support something like that because we
can really only serialize values of P across to the server.
This will be changed with PR #815 that introduces new interfaces, one of
which is `IPredicate` that we use in Gremlin.Net in places where Java uses
`Predicate`. My idea was that users could write either predicates in the form
of lambdas (PR #814) or implement their own predicates which would also require
their own serialization. Geo-predicates or full-text search are an example
where implementing custom predicates like this would make sense.
I'll add something for the upgrade docs. Although it will probably just
concentrate on cases where users already implemented their own predicates as
there should be no visible changes for users that only used our predicates.
`P.gt(1).and(P.lt(3))` can still be called exactly the same way. The only
difference is that they now get back a `P` object instead of a
`TraversalPredicate`.
> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both
> classes or we could also just merge those two classes together. I think the
> reason why they are split was simply that the methods in
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely
> generated and I didn't want to write much code inside of Groovy strings that
> were part of the {{pom.xml}} before [~spmallette] introduced templates for
> the GLV generation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #816: TINKERPOP-1919 Merge classes P and TraversalPredicate ...
Github user FlorianHockmann commented on the issue: https://github.com/apache/tinkerpop/pull/816 >I think this is a good change though it doesn't exactly mimic the Java API right? there is no until(P) in java - it's until(Predicate), but I guess that doesn't really make sense in this GLV to support something like that because we can really only serialize values of P across to the server. This will be changed with PR #815 that introduces new interfaces, one of which is `IPredicate` that we use in Gremlin.Net in places where Java uses `Predicate`. My idea was that users could write either predicates in the form of lambdas (PR #814) or implement their own predicates which would also require their own serialization. Geo-predicates or full-text search are an example where implementing custom predicates like this would make sense. I'll add something for the upgrade docs. Although it will probably just concentrate on cases where users already implemented their own predicates as there should be no visible changes for users that only used our predicates. `P.gt(1).and(P.lt(3))` can still be called exactly the same way. The only difference is that they now get back a `P` object instead of a `TraversalPredicate`. ---
[jira] [Commented] (TINKERPOP-1896) gremlin-python lambdas error
[
https://issues.apache.org/jira/browse/TINKERPOP-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396846#comment-16396846
]
ASF GitHub Bot commented on TINKERPOP-1896:
---
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/814
Makes sense, VOTE +1
> gremlin-python lambdas error
>
>
> Key: TINKERPOP-1896
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1896
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.3.1
>Reporter: Branden Moore
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin-python lambdas throw an error on the server when the preceding step
> produces maps.
> {code}
> Traceback (most recent call last):
> File "foo.py", line 15, in
> print g.V().has('name').match(__.as_('x').label().as_('lbl'),
> __.as_('x').id().as_('id')).select('lbl', 'id').map(lambda: "lambda x:
> type(x)").toList()
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 52, in toList
> return list(iter(self))
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 70, in next
> return self.__next__()
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 43, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
> line 352, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/remote_connection.py",
> line 143, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/driver_remote_connection.py",
> line 54, in submit
> results = result_set.all().result()
> File
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line
> 462, in result
> return self.__get_result()
> File
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line
> 414, in __get_result
> raise exception_type, self._exception, self._traceback
> gremlin_python.driver.protocol.GremlinServerError: 599: AttributeError: type
> object 'org.apache.tinkerpop.gremlin.process.traversal.dsl' has no attribute
> 'as_' in
[GitHub] tinkerpop issue #814: TINKERPOP-1896 Fixed bug in lambda processing for pyth...
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/814 Makes sense, VOTE +1 ---
[jira] [Commented] (TINKERPOP-1901) Enable usage of enums in more steps in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396831#comment-16396831
]
ASF GitHub Bot commented on TINKERPOP-1901:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/815
VOTE +1
> Enable usage of enums in more steps in Gremlin.Net
> --
>
> Key: TINKERPOP-1901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1901
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> Java enums can implement interfaces and some Gremlin steps take interfaces as
> arguments that are implemented by enums like {{T}} or {{P}} in Java. However,
> C# enums can't have any methods and therefore also not implement interfaces.
> For this reason, step arguments whose type is one of those interfaces
> ({{Predicate}}, {{Function}}, ...) currently have the type {{object}} in
> Gremlin.Net which makes it hard for users to know what kind of values they
> can use for these arguments.
> This overload of the {{By}} step is a good example for this:
> * In Gremlin-java:
> {code:java}
> public default GraphTraversal by(final Traversal traversal,
> final Comparator comparator)
> {code}
> * In Gremlin.Net:
> {code}
> public GraphTraversal By (object function, object comparator)
> {code}
> [~jorgebg] [suggested two possible
> solutions|https://github.com/apache/tinkerpop/pull/792#discussion_r167847541]
> for this problem:
> {quote} * Use a class for T (not an enum), properties like T.Id could return
> instances of whatever interface we create for it. Given that java enums
> functionality is more comprehensive than what C# currently supports, it makes
> sense to use a class IMO.
> * Generate the offending traversal methods manually.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #815: TINKERPOP-1901 Transform enums into classes in Gremlin...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/815 VOTE +1 ---
[jira] [Commented] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396830#comment-16396830
]
ASF GitHub Bot commented on TINKERPOP-1919:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/816
I think this is a good change though it doesn't exactly mimic the Java API
right? there is no `until(P)` in java - it's `until(Predicate)`, but I guess
that doesn't really make sense in this GLV to support something like that
because we can really only serialize values of `P` across to the server.
I agree that most folks will not have used this `TraversalPredicate` aspect
of the API, so I agree that we can allow this breaking change to occur.
However, I think that you should call more attention to it by adding something
to the upgrade docs that describes the change and shows what the code used to
look like and what it should look like now.
Does all of that make sense?
> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both
> classes or we could also just merge those two classes together. I think the
> reason why they are split was simply that the methods in
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely
> generated and I didn't want to write much code inside of Groovy strings that
> were part of the {{pom.xml}} before [~spmallette] introduced templates for
> the GLV generation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #816: TINKERPOP-1919 Merge classes P and TraversalPredicate ...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/816 I think this is a good change though it doesn't exactly mimic the Java API right? there is no `until(P)` in java - it's `until(Predicate)`, but I guess that doesn't really make sense in this GLV to support something like that because we can really only serialize values of `P` across to the server. I agree that most folks will not have used this `TraversalPredicate` aspect of the API, so I agree that we can allow this breaking change to occur. However, I think that you should call more attention to it by adding something to the upgrade docs that describes the change and shows what the code used to look like and what it should look like now. Does all of that make sense? ---
[GitHub] tinkerpop issue #772: TINKERPOP-1861 Modify VertexProgram Builder to take va...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/772 @PBGraff i just thought i'd reach out to let you know that we do have a release coming up soon - aimed for first week of april (though we'd probably look to stop making code changes in preparation for that on March 23). Do you think there is any chance you might have time to come back to this PR in time for that release? if not, that's fine, i just wanted you to be aware that a release was upcoming and if this issue was important to you and you needed it for your work in the next release, that time is coming up. thanks ---
[jira] [Commented] (TINKERPOP-1861) VertexProgram create with varargs for Graphs
[ https://issues.apache.org/jira/browse/TINKERPOP-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396823#comment-16396823 ] ASF GitHub Bot commented on TINKERPOP-1861: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/772 @PBGraff i just thought i'd reach out to let you know that we do have a release coming up soon - aimed for first week of april (though we'd probably look to stop making code changes in preparation for that on March 23). Do you think there is any chance you might have time to come back to this PR in time for that release? if not, that's fine, i just wanted you to be aware that a release was upcoming and if this issue was important to you and you needed it for your work in the next release, that time is coming up. thanks > VertexProgram create with varargs for Graphs > > > Key: TINKERPOP-1861 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1861 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.7 >Reporter: Philip Graff >Priority: Minor > > VertexProgram.Builder.create(Graph) can be modified to > VertexProgram.Builder.create(Graph...) so that passing in zero or many graphs > is naturally handled. The current state of passing in null when no graph is > needed is bad practice. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1919) Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396681#comment-16396681
]
ASF GitHub Bot commented on TINKERPOP-1919:
---
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/816
Down to just 32 ignored!
VOTE +1
> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> --
>
> Key: TINKERPOP-1919
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net has split {{P}} into two classes: {{P}} and
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both
> classes or we could also just merge those two classes together. I think the
> reason why they are split was simply that the methods in
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely
> generated and I didn't want to write much code inside of Groovy strings that
> were part of the {{pom.xml}} before [~spmallette] introduced templates for
> the GLV generation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #816: TINKERPOP-1919 Merge classes P and TraversalPredicate ...
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/816 Down to just 32 ignored! VOTE +1 ---
