[jira] [Commented] (TINKERPOP-1801) OLAP profile() step return incorrect timing
[
https://issues.apache.org/jira/browse/TINKERPOP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225848#comment-16225848
]
ASF GitHub Bot commented on TINKERPOP-1801:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/734
@okram if all looks good to you after artem's changes you should be free to
merge this now:
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
> OLAP profile() step return incorrect timing
>
>
> Key: TINKERPOP-1801
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1801
> Project: TinkerPop
> Issue Type: Bug
> Components: hadoop
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Artem Aliev
>
> Graph ProfileStep calculates time of next()/hasNext() calls, expecting
> recursion.
> But Message passing/RDD joins is used by GraphComputer.
> So next() does not recursively call next steps, but message is generated. And
> most of the time is taken by message passing (RDD join).
> Thus on graph computer the time between ProfileStep should be measured, not
> inside it.
> The other approach is to get Spark statistics with SparkListener and add
> spark stages timings into profiler metrics. that will work only for spark but
> will give better representation of step costs.
> The simple fix is measuring time between OLAP iterations and add it to the
> profiler step.
> This will not take into account computer setup time, but will be precise
> enough for long running queries.
> To reproduce:
> tinkerPop 3.2.6 gremlin:
> {code}
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.spark
> plugin activated: tinkerpop.tinkergraph
> gremlin> graph =
> GraphFactory.open('conf/hadoop/hadoop-grateful-gryo.properties')
> gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
> ==>graphtraversalsource[hadoopgraph[gryoinputformat->gryooutputformat],
> sparkgraphcomputer]
> gremlin> g.V().out().out().count().profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> GraphStep(vertex,[]) 808
>808 2.02518.35
> VertexStep(OUT,vertex) 8049
>562 4.43040.14
> VertexStep(OUT,edge) 327370
> 7551 4.58141.50
> CountGlobalStep1
> 1 0.001 0.01
> >TOTAL -
> - 11.038-
> gremlin> clock(1){g.V().out().out().count().next() }
> ==>3421.92758
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop issue #734: TINKERPOP-1801: fix profile() timing in OLAP by adding...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/734 @okram if all looks good to you after artem's changes you should be free to merge this now: All tests pass with `docker/build.sh -t -n -i` VOTE +1 ---
[jira] [Commented] (TINKERPOP-1821) Consistent behavior of self-referencing edges
[
https://issues.apache.org/jira/browse/TINKERPOP-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225768#comment-16225768
]
ASF GitHub Bot commented on TINKERPOP-1821:
---
GitHub user okram opened a pull request:
https://github.com/apache/tinkerpop/pull/739
TINKERPOP-1821: Consistent behavior of self-referencing edges
https://issues.apache.org/jira/browse/TINKERPOP-1821
Added test for self-edges and fixed a semantic issue in `Neo4jGraph`
regarding self edges not being repeated on `BOTH`.
VOTE +1.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1821
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/739.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #739
commit 7f640f7e6d863cde1858d6bfa3ff502fd93a8663
Author: Stephen Mallette
Date: 2017-10-30T15:06:02Z
TINKERPOP-1821 Added tests for consistent traversal behavior around
self-referencing edges
commit 5d68ca17160e4977eddfdb688f93d37440897957
Author: Marko A. Rodriguez
Date: 2017-10-30T21:28:37Z
fixed up a self-edge test and Neo4jVertex to support repeat edges on BOTH.
> Consistent behavior of self-referencing edges
> -
>
> Key: TINKERPOP-1821
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1821
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>
> Given discussions here:
> https://lists.apache.org/thread.html/adcfa13130026896da215be257fd26b309820c1cd5b5d359ed9cdfa2@%3Cdev.tinkerpop.apache.org%3E
> we needed to include a test to ensure consistency of the traversal behavior
> around self-referencing edges in relation to
> {code}
> g.V().bothE()
> g.V().both()
> {code}
> The expected behavior is already present in TinkerGraph and that expected
> behavior is as follows:
> {code}
> gremlin> g.addV().as("a").addE("self").to("a").iterate()
> gremlin> g.V().bothE()
> ==>e[19][18-self->18]
> ==>e[19][18-self->18]
> gremlin> g.V().both()
> ==>v[18]
> ==>v[18]
> {code}
> This may break a number of providers as we've not had a test for this
> behavior until now - we should provide some upgrade documentation to call
> attention to this issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop pull request #739: TINKERPOP-1821: Consistent behavior of self-ref...
GitHub user okram opened a pull request: https://github.com/apache/tinkerpop/pull/739 TINKERPOP-1821: Consistent behavior of self-referencing edges https://issues.apache.org/jira/browse/TINKERPOP-1821 Added test for self-edges and fixed a semantic issue in `Neo4jGraph` regarding self edges not being repeated on `BOTH`. VOTE +1. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1821 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/739.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #739 commit 7f640f7e6d863cde1858d6bfa3ff502fd93a8663 Author: Stephen Mallette Date: 2017-10-30T15:06:02Z TINKERPOP-1821 Added tests for consistent traversal behavior around self-referencing edges commit 5d68ca17160e4977eddfdb688f93d37440897957 Author: Marko A. Rodriguez Date: 2017-10-30T21:28:37Z fixed up a self-edge test and Neo4jVertex to support repeat edges on BOTH. ---
Re: [DISCUSS] GLV Test Suite
I guess there wouldn't be a problem with that, though having it the way it
works now was a nice check to ensure that the ScriptEngine was configured
properly. I guess that shouldn't be the focus on this body of tests though.
We should be more concerned that the elements of the Gremlin language
actually work.
On Thu, Oct 26, 2017 at 8:47 AM, Jorge Bay Gondra
wrote:
> I see that for most languages using bytecode to native language translator
> would be the easiest solution. In the case of the JavaScript GLV, it would
> be fairly straightforward to implement (and I plan to do so!).
> In the case of C#, being more strict regarding typing than java, it would
> be an incomplete solution. For example:
>
> Consider the following traversal in Java: g.V().values("age")
> The type parameter for values() method is inferred at runtime and things
> "just works" thanks to type erasure.
>
> In the case of C#, it should be written as g.V().Values("age") , with
> the type parameter to specify which type of traverser are you expecting at
> a compile time.
>
> That's why it wont be possible to make a generic translator from bytecode
> to C# code, without understanding which generic types are expected.
>
> In the case of C#, I was going for a translator on the C# side that
> tokenizes the gremlin traversal. Once the traversal is tokenized, in the
> moment of invoking the methods (with reflection), it can be made aware of
> the modern graph data (with datatypes!), ie: For method Values<>(), if the
> property key is "age" -> use int as generic type parameter.
>
> On Thu, Oct 26, 2017 at 2:12 PM, Stephen Mallette
> wrote:
>
> > I can't help thinking that perhaps non-JVM languages need to leverage
> > bytecode to make traversal building easier. We already have an
> established
> > pattern for converting bytecode into Traversals and while it is different
> > for each language, it's generally governed by the Translator interface.
> > Note that we already do this for Java, Groovy, and Python and the code
> > isn't too crazy - just 200 lines or so:
> >
> > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > core/src/main/java/org/apache/tinkerpop/gremlin/jsr223/
> JavaTranslator.java
> > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/
> > GroovyTranslator.java
> > https://github.com/apache/tinkerpop/blob/master/gremlin-
> > python/src/main/java/org/apache/tinkerpop/gremlin/python/jsr223/
> > PythonTranslator.java
> >
> > I think that non-JVM languages could send the Gremlin string from the
> test
> > to Gremlin Server as a script first and return the bytecode as JSON. Then
> > it could use a "Translator" to then parse it into it's native language.
> > Shouldn't we just build a CSharpTranslator similar to these? does that
> make
> > sense?
> >
> >
> > On Wed, Oct 25, 2017 at 11:11 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > > wrote:
> >
> > > I've been looking over the current test scenarios on the TINKERPOP-1784
> > > branch, with the C# GLV test suite in mind, and oh man that's an
> > impressive
> > > amount of scenarios!
> > >
> > > So far, I have a suggestion.
> > >
> > > Instead of
> > >
> > > Scenario: g_V_fold_countXlocalX
> > > Given the modern graph
> > > And the traversal of
> > > """
> > > g.V().fold().count(Scope.local)
> > > """
> > >
> > > We could use
> > >
> > > Scenario: g_V_fold_countXlocalX
> > > Given the modern graph
> > > And parameter 1 being an enum
> > > """
> > > Scope.local
> > > """
> > > And the traversal of
> > > """
> > > g.V().fold().count(param1)
> > > """
> > >
> > > That way we can exclude enums from possible parameter values, narrowing
> > > down the amount of types of parameters allowed, ie: const numeric,
> const
> > > strings (wrapped in double quotes), traversals (starting with `__`) ,
> > ...,
> > > making parsing the traversal a little easier.
> > >
> > >
> > > On Thu, Oct 12, 2017 at 8:54 PM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > Just a quick update on this item - it continues
> > > >
> > > > Went down a bad path earlier in the week and ended up shelving a lot
> of
> > > > work - ended up just coded into a corner. Anyway, I've not really
> > changed
> > > > much in the implementation, but I've still not reached a point where
> > the
> > > > addition of a new .feature files comes without meeting some new type
> of
> > > > assertion that has to be dealt with. This ends up slowing down
> progress
> > > on
> > > > porting over the tests. Please feel free to peruse the latest changes
> > on
> > > > the branch and let me know if there's any feedback.
> > > >
> > > >
> > > >
> > > > On Fri, Sep 29, 2017 at 12:05 PM, Stephen Mallette <
> > spmalle...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I did some pretty heavy refactoring to the python test logic
> > (altered a
> > > >
[jira] [Updated] (TINKERPOP-1820) Include Python and .NET GLV tests on TravisCI
[ https://issues.apache.org/jira/browse/TINKERPOP-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1820: Issue Type: Improvement (was: Test) > Include Python and .NET GLV tests on TravisCI > - > > Key: TINKERPOP-1820 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1820 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, python >Reporter: Jorge Bay > > We can avoid the need of manual test runs by using TravisCI to run both GLVs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: CountStrategy and TraversalHelper.replaceStep
Ok great, I'll test a bit with the order changed.
Thanks,
Pieter
On 30/10/2017 18:01, Daniel Kuppitz wrote:
Ah, yea, I see what you mean. It's actually replaceStep() which is buggy,
not the strategy. The fix is easy, we just need to change the order of the
2 statements in replaceStep():
public static void replaceStep(final Step removeStep,
final Step insertStep, final Traversal.Admin traversal) {
final int i;traversal.removeStep(i = stepIndex(removeStep,
traversal));traversal.addStep(i, insertStep);}
Cheers,
Daniel
On Mon, Oct 30, 2017 at 7:43 AM, pieter gmail
wrote:
I am on the latest 3.3.1-SNAPSHOT, just pulled master again.
The actual traversals and results are correct. However after the
CountStrategy the VertexStep(OUT,edge) previousStep pointer
(AbstractStep.previousStep) is incorrect. I should be EmptyStep but infact
points to the newly inserted NotStep.
toString() on a traversal does not show the previous/nextStep so you can
not see what I am talking about in the console. This is not breaking
anything in TinkerGraph but breaks stuff in Sqlg.
In CountStrategy if I change line 153 to then my problems go away and
TinkerGraph also works as expected.
//TraversalHelper.replaceStep(prev, new NotStep<>(traversal, inner),
traversal);
NotStep notStep = new NotStep<>(traversal, inner);
TraversalHelper.replaceStep(prev, notStep, traversal);
List> notStepTraversal = notStep.getLocalChildren();
Traversal.Admin notStepTraversalFirstStep = notStepTraversal.get(0);
//The first step is pointing to the NotStep, it should point to an
EmptyStep
notStepTraversalFirstStep.getSteps().get(0).setPreviousStep(
EmptyStep.instance());
So I suppose the question is, is it correct for the previousStep of the
first step of a local traversal to point to the parent step and not an
EmptyStep?
The TraversalHelper.replaceStep always makes the first step of the
traversal point to the newly inserted step. If the traversal however is a
local traversal then the root step should be an EmptyStep.
Hope it makes some sense.
Thanks
Pieter
On 30/10/2017 15:28, Daniel Kuppitz wrote:
I don't see any issues. Which version are you talking about?
*gremlin> Gremlin.version()*
*==>3.2.7-SNAPSHOT*
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin>
g.V(1).repeat(out()).until(__.not(outE())).values('name').it
erate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
gremlin>
g.V(1).repeat(out()).until(outE().count().is(0)).values('nam
e').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
*gremlin> Gremlin.version()*
*==>3.3.1-SNAPSHOT*
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin>
g.V(1).repeat(out()).until(__.not(outE())).values('name').it
erate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
gremlin>
g.V(1).repeat(out()).until(outE().count().is(0)).values('nam
e').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
Cheers,
Daniel
On Mon, Oct 30, 2017 at 1:53 AM, pieter gmail
wrote:
Hi,
Whilst optimizing the NotStep I came across what looks to me like a bug
in
TraversalHelper.replaceStep or perhaps rather in CountStrategy.
The test below shows the bug.
@Test
public void g_VX1X_repeatXoutX_untilXoutE_count_isX0XX_name() {
Graph graph = TinkerFactory.createModern();
final Traversal traversal1 = graph.traversal()
.V(convertToVertexId(graph, "marko"))
.repeat(__.out())
.until(__.not(__.outE()))
.values("name");
checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
traversal1);
List vertexSteps = TraversalHelper.getStepsOfAssi
gnableClassRecursively(VertexStep.class, traversal1.asAdmin());
VertexStep vertexStep = vertexSteps.stream().filter(s ->
s.returnsEdge()).findAny().get();
Assert.assertEquals(EmptyStep.instance(),
vertexStep.getPreviousStep());
fina
Re: CountStrategy and TraversalHelper.replaceStep
Ah, yea, I see what you mean. It's actually replaceStep() which is buggy,
not the strategy. The fix is easy, we just need to change the order of the
2 statements in replaceStep():
public static void replaceStep(final Step removeStep,
final Step insertStep, final Traversal.Admin traversal) {
final int i;traversal.removeStep(i = stepIndex(removeStep,
traversal));traversal.addStep(i, insertStep);}
Cheers,
Daniel
On Mon, Oct 30, 2017 at 7:43 AM, pieter gmail
wrote:
> I am on the latest 3.3.1-SNAPSHOT, just pulled master again.
>
> The actual traversals and results are correct. However after the
> CountStrategy the VertexStep(OUT,edge) previousStep pointer
> (AbstractStep.previousStep) is incorrect. I should be EmptyStep but infact
> points to the newly inserted NotStep.
>
> toString() on a traversal does not show the previous/nextStep so you can
> not see what I am talking about in the console. This is not breaking
> anything in TinkerGraph but breaks stuff in Sqlg.
>
> In CountStrategy if I change line 153 to then my problems go away and
> TinkerGraph also works as expected.
>
> //TraversalHelper.replaceStep(prev, new NotStep<>(traversal, inner),
> traversal);
> NotStep notStep = new NotStep<>(traversal, inner);
> TraversalHelper.replaceStep(prev, notStep, traversal);
> List> notStepTraversal = notStep.getLocalChildren();
> Traversal.Admin notStepTraversalFirstStep = notStepTraversal.get(0);
> //The first step is pointing to the NotStep, it should point to an
> EmptyStep
> notStepTraversalFirstStep.getSteps().get(0).setPreviousStep(
> EmptyStep.instance());
>
> So I suppose the question is, is it correct for the previousStep of the
> first step of a local traversal to point to the parent step and not an
> EmptyStep?
>
> The TraversalHelper.replaceStep always makes the first step of the
> traversal point to the newly inserted step. If the traversal however is a
> local traversal then the root step should be an EmptyStep.
>
> Hope it makes some sense.
>
> Thanks
> Pieter
>
>
>
> On 30/10/2017 15:28, Daniel Kuppitz wrote:
>
>> I don't see any issues. Which version are you talking about?
>>
>> *gremlin> Gremlin.version()*
>> *==>3.2.7-SNAPSHOT*
>> gremlin> g = TinkerFactory.createModern().traversal()
>> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>> gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
>> ==>lop
>> ==>vadas
>> ==>ripple
>> ==>lop
>> gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
>> ==>lop
>> ==>vadas
>> ==>ripple
>> ==>lop
>> gremlin>
>> g.V(1).repeat(out()).until(__.not(outE())).values('name').it
>> erate().toString()
>> ==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
>> RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
>> PropertiesStep([name],value)]
>> gremlin>
>> g.V(1).repeat(out()).until(outE().count().is(0)).values('nam
>> e').iterate().toString()
>> ==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
>> RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
>> PropertiesStep([name],value)]
>>
>>
>> *gremlin> Gremlin.version()*
>> *==>3.3.1-SNAPSHOT*
>>
>> gremlin> g = TinkerFactory.createModern().traversal()
>> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
>> gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
>> ==>lop
>> ==>vadas
>> ==>ripple
>> ==>lop
>> gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
>> ==>lop
>> ==>vadas
>> ==>ripple
>> ==>lop
>> gremlin>
>> g.V(1).repeat(out()).until(__.not(outE())).values('name').it
>> erate().toString()
>> ==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
>> RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
>> PropertiesStep([name],value)]
>> gremlin>
>> g.V(1).repeat(out()).until(outE().count().is(0)).values('nam
>> e').iterate().toString()
>> ==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
>> RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
>> PropertiesStep([name],value)]
>>
>>
>> Cheers,
>> Daniel
>>
>>
>> On Mon, Oct 30, 2017 at 1:53 AM, pieter gmail
>> wrote:
>>
>> Hi,
>>>
>>> Whilst optimizing the NotStep I came across what looks to me like a bug
>>> in
>>> TraversalHelper.replaceStep or perhaps rather in CountStrategy.
>>>
>>> The test below shows the bug.
>>>
>>> @Test
>>> public void g_VX1X_repeatXoutX_untilXoutE_count_isX0XX_name() {
>>> Graph graph = TinkerFactory.createModern();
>>> final Traversal traversal1 = graph.traversal()
>>> .V(convertToVertexId(graph, "marko"))
>>> .repeat(__.out())
>>> .until(__.not(__.outE()))
>>> .values("name");
>>> checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
>>> traversal1);
>>>
>>> List vertexSteps = TraversalHelper.getStepsOfAssi
>>> gnableClassRecursively(VertexStep.class, travers
[jira] [Created] (TINKERPOP-1821) Consistent behavior of self-referencing edges
stephen mallette created TINKERPOP-1821:
---
Summary: Consistent behavior of self-referencing edges
Key: TINKERPOP-1821
URL: https://issues.apache.org/jira/browse/TINKERPOP-1821
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.2.6
Reporter: stephen mallette
Assignee: Marko A. Rodriguez
Given discussions here:
https://lists.apache.org/thread.html/adcfa13130026896da215be257fd26b309820c1cd5b5d359ed9cdfa2@%3Cdev.tinkerpop.apache.org%3E
we needed to include a test to ensure consistency of the traversal behavior
around self-referencing edges in relation to
{code}
g.V().bothE()
g.V().both()
{code}
The expected behavior is already present in TinkerGraph and that expected
behavior is as follows:
{code}
gremlin> g.addV().as("a").addE("self").to("a").iterate()
gremlin> g.V().bothE()
==>e[19][18-self->18]
==>e[19][18-self->18]
gremlin> g.V().both()
==>v[18]
==>v[18]
{code}
This may break a number of providers as we've not had a test for this behavior
until now - we should provide some upgrade documentation to call attention to
this issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1819) documentation query and description mismatch
[
https://issues.apache.org/jira/browse/TINKERPOP-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225084#comment-16225084
]
Chandran Anjur Narasimhan commented on TINKERPOP-1819:
--
That was fast, nice !
> documentation query and description mismatch
>
>
> Key: TINKERPOP-1819
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1819
> Project: TinkerPop
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.3.0
>Reporter: Chandran Anjur Narasimhan
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.7, 3.3.1
>
>
> http://tinkerpop.apache.org/docs/current/reference/
> Section: Graph Traversal Steps->General Steps
> Query: gremlin> g.V().filter {it.get().label() == 'person'} //1
> Explanation (wrong): A filter that only allows the vertex to pass if it has
> an age-property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: CountStrategy and TraversalHelper.replaceStep
I am on the latest 3.3.1-SNAPSHOT, just pulled master again.
The actual traversals and results are correct. However after the
CountStrategy the VertexStep(OUT,edge) previousStep pointer
(AbstractStep.previousStep) is incorrect. I should be EmptyStep but
infact points to the newly inserted NotStep.
toString() on a traversal does not show the previous/nextStep so you can
not see what I am talking about in the console. This is not breaking
anything in TinkerGraph but breaks stuff in Sqlg.
In CountStrategy if I change line 153 to then my problems go away and
TinkerGraph also works as expected.
//TraversalHelper.replaceStep(prev, new NotStep<>(traversal, inner),
traversal);
NotStep notStep = new NotStep<>(traversal, inner);
TraversalHelper.replaceStep(prev, notStep, traversal);
List> notStepTraversal = notStep.getLocalChildren();
Traversal.Admin notStepTraversalFirstStep = notStepTraversal.get(0);
//The first step is pointing to the NotStep, it should point to an EmptyStep
notStepTraversalFirstStep.getSteps().get(0).setPreviousStep(EmptyStep.instance());
So I suppose the question is, is it correct for the previousStep of the
first step of a local traversal to point to the parent step and not an
EmptyStep?
The TraversalHelper.replaceStep always makes the first step of the
traversal point to the newly inserted step. If the traversal however is
a local traversal then the root step should be an EmptyStep.
Hope it makes some sense.
Thanks
Pieter
On 30/10/2017 15:28, Daniel Kuppitz wrote:
I don't see any issues. Which version are you talking about?
*gremlin> Gremlin.version()*
*==>3.2.7-SNAPSHOT*
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin>
g.V(1).repeat(out()).until(__.not(outE())).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
gremlin>
g.V(1).repeat(out()).until(outE().count().is(0)).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
*gremlin> Gremlin.version()*
*==>3.3.1-SNAPSHOT*
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin>
g.V(1).repeat(out()).until(__.not(outE())).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
gremlin>
g.V(1).repeat(out()).until(outE().count().is(0)).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
Cheers,
Daniel
On Mon, Oct 30, 2017 at 1:53 AM, pieter gmail
wrote:
Hi,
Whilst optimizing the NotStep I came across what looks to me like a bug in
TraversalHelper.replaceStep or perhaps rather in CountStrategy.
The test below shows the bug.
@Test
public void g_VX1X_repeatXoutX_untilXoutE_count_isX0XX_name() {
Graph graph = TinkerFactory.createModern();
final Traversal traversal1 = graph.traversal()
.V(convertToVertexId(graph, "marko"))
.repeat(__.out())
.until(__.not(__.outE()))
.values("name");
checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
traversal1);
List vertexSteps = TraversalHelper.getStepsOfAssi
gnableClassRecursively(VertexStep.class, traversal1.asAdmin());
VertexStep vertexStep = vertexSteps.stream().filter(s ->
s.returnsEdge()).findAny().get();
Assert.assertEquals(EmptyStep.instance(),
vertexStep.getPreviousStep());
final Traversal traversal2 = graph.traversal()
.V(convertToVertexId(graph, "marko"))
.repeat(__.out())
.until(__.outE().count().is(0))
.values("name");
checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
traversal2);
vertexSteps = TraversalHelper.getStepsOfAssi
gnableClassRecursively(VertexStep.class, traversal2.asAdmin());
vertexStep = vertexSteps.stream().filter(s ->
s.returnsEdge()).findAny().get();
//This fails because the vertexStep's previous step is the
NotStepwhen it should be
[jira] [Commented] (TINKERPOP-1820) Include Python and .NET GLV tests on TravisCI
[ https://issues.apache.org/jira/browse/TINKERPOP-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225044#comment-16225044 ] ASF GitHub Bot commented on TINKERPOP-1820: --- Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/738 > I see that you used the -q option. What happens if there is a failure in native python tests? currently i don't see any output for those, i'm wondering how that will fail when it does. I was looking for ways to limit the output, TravisCI only accepts up to 4Mb which is a lot... On previous commits I've tried to set either: `-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn` or `-Dorg.slf4j.simpleLogger.defaultLogLevel=WARN` But it was not being considered by `mvn`. Maybe including any of [those options on the root pom](https://github.com/apache/tinkerpop/blob/2e4f8bf7c3a1c9e39729ab5aab4886f1f469d641/pom.xml#L1335-L1336) would work, that way I could remove the quiet flag, wdyt? > I think it's good to include the GLVs on Travis, but it won't eliminate local builds completely because travis doesn't run integration tests - nor do we want it to probably. hmm... Looking at the output, I see that both unit and integration tests are run for Gremlin.Net which is unexpected (would be the only module doing both). Now that I think of it, maybe it would be best to run different jobs on the same build, using [a build matrix](https://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix) or even [build steps](https://docs.travis-ci.com/user/build-stages/define-steps/). That way we could run individual profiles (glvs, integration tests for different modules, ...) in different jobs for the same build. We should find a way to continuously run most of the test suite, to ease the burden of having to run it locally. > Include Python and .NET GLV tests on TravisCI > - > > Key: TINKERPOP-1820 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1820 > Project: TinkerPop > Issue Type: Test > Components: dotnet, python >Reporter: Jorge Bay > > We can avoid the need of manual test runs by using TravisCI to run both GLVs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #738: TINKERPOP-1820 Include Python and .NET GLVs on TravisC...
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/738 > I see that you used the -q option. What happens if there is a failure in native python tests? currently i don't see any output for those, i'm wondering how that will fail when it does. I was looking for ways to limit the output, TravisCI only accepts up to 4Mb which is a lot... On previous commits I've tried to set either: `-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn` or `-Dorg.slf4j.simpleLogger.defaultLogLevel=WARN` But it was not being considered by `mvn`. Maybe including any of [those options on the root pom](https://github.com/apache/tinkerpop/blob/2e4f8bf7c3a1c9e39729ab5aab4886f1f469d641/pom.xml#L1335-L1336) would work, that way I could remove the quiet flag, wdyt? > I think it's good to include the GLVs on Travis, but it won't eliminate local builds completely because travis doesn't run integration tests - nor do we want it to probably. hmm... Looking at the output, I see that both unit and integration tests are run for Gremlin.Net which is unexpected (would be the only module doing both). Now that I think of it, maybe it would be best to run different jobs on the same build, using [a build matrix](https://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix) or even [build steps](https://docs.travis-ci.com/user/build-stages/define-steps/). That way we could run individual profiles (glvs, integration tests for different modules, ...) in different jobs for the same build. We should find a way to continuously run most of the test suite, to ease the burden of having to run it locally. ---
Re: CountStrategy and TraversalHelper.replaceStep
I don't see any issues. Which version are you talking about?
*gremlin> Gremlin.version()*
*==>3.2.7-SNAPSHOT*
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin>
g.V(1).repeat(out()).until(__.not(outE())).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
gremlin>
g.V(1).repeat(out()).until(outE().count().is(0)).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
*gremlin> Gremlin.version()*
*==>3.3.1-SNAPSHOT*
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1).repeat(out()).until(__.not(outE())).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin> g.V(1).repeat(out()).until(outE().count().is(0)).values('name')
==>lop
==>vadas
==>ripple
==>lop
gremlin>
g.V(1).repeat(out()).until(__.not(outE())).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
gremlin>
g.V(1).repeat(out()).until(outE().count().is(0)).values('name').iterate().toString()
==>[TinkerGraphStep(vertex,[1]), RepeatStep([VertexStep(OUT,vertex),
RepeatEndStep],until([NotStep([VertexStep(OUT,edge)])]),emit(false)),
PropertiesStep([name],value)]
Cheers,
Daniel
On Mon, Oct 30, 2017 at 1:53 AM, pieter gmail
wrote:
> Hi,
>
> Whilst optimizing the NotStep I came across what looks to me like a bug in
> TraversalHelper.replaceStep or perhaps rather in CountStrategy.
>
> The test below shows the bug.
>
> @Test
> public void g_VX1X_repeatXoutX_untilXoutE_count_isX0XX_name() {
> Graph graph = TinkerFactory.createModern();
> final Traversal traversal1 = graph.traversal()
> .V(convertToVertexId(graph, "marko"))
> .repeat(__.out())
> .until(__.not(__.outE()))
> .values("name");
> checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
> traversal1);
>
> List vertexSteps = TraversalHelper.getStepsOfAssi
> gnableClassRecursively(VertexStep.class, traversal1.asAdmin());
> VertexStep vertexStep = vertexSteps.stream().filter(s ->
> s.returnsEdge()).findAny().get();
> Assert.assertEquals(EmptyStep.instance(),
> vertexStep.getPreviousStep());
>
> final Traversal traversal2 = graph.traversal()
> .V(convertToVertexId(graph, "marko"))
> .repeat(__.out())
> .until(__.outE().count().is(0))
> .values("name");
> checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
> traversal2);
>
> vertexSteps = TraversalHelper.getStepsOfAssi
> gnableClassRecursively(VertexStep.class, traversal2.asAdmin());
> vertexStep = vertexSteps.stream().filter(s ->
> s.returnsEdge()).findAny().get();
>
> //This fails because the vertexStep's previous step is the
> NotStepwhen it should be an EmptyStep.
> Assert.assertEquals(EmptyStep.instance(),
> vertexStep.getPreviousStep());
> }
>
> traversal1 and traversal2 should be the same as the CountStrategy will
> replace the __.outE().count().is(0) with __.not(__.outE())
> The CountStrategy does what its suppose to do however then it calls
> TraversalHelper.replaceStep(prev, new NotStep<>(traversal, inner),
> traversal); the traversal's VertexStep gets its previousStep set to the
> NotStep. This is because of the way TraversalHelper.replaceStep is
> implemented.
>
> I am not sure whether the fix should be in replaceStep or rather in
> CountStrategy.
>
> Thanks
> Pieter
>
[jira] [Commented] (TINKERPOP-1801) OLAP profile() step return incorrect timing
[
https://issues.apache.org/jira/browse/TINKERPOP-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224914#comment-16224914
]
ASF GitHub Bot commented on TINKERPOP-1801:
---
Github user artem-aliev commented on the issue:
https://github.com/apache/tinkerpop/pull/734
I have fixed test failures.
TinkerPopComputer does not call ComputerPorgram.execute methods if spit
has no vertices.
For example: modern graph has 6 vertices but computer has 8 cores,
there will be two empty splits.
TraversalVertexProgram use execute step to setup next profiling step,
so it is not setup side effects properly for empty splits.
So tests did not filed in docker but failed on computer with more then
6 cores.
The fix add check that profile side effects were regester properly
before using
> OLAP profile() step return incorrect timing
>
>
> Key: TINKERPOP-1801
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1801
> Project: TinkerPop
> Issue Type: Bug
> Components: hadoop
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Artem Aliev
>
> Graph ProfileStep calculates time of next()/hasNext() calls, expecting
> recursion.
> But Message passing/RDD joins is used by GraphComputer.
> So next() does not recursively call next steps, but message is generated. And
> most of the time is taken by message passing (RDD join).
> Thus on graph computer the time between ProfileStep should be measured, not
> inside it.
> The other approach is to get Spark statistics with SparkListener and add
> spark stages timings into profiler metrics. that will work only for spark but
> will give better representation of step costs.
> The simple fix is measuring time between OLAP iterations and add it to the
> profiler step.
> This will not take into account computer setup time, but will be precise
> enough for long running queries.
> To reproduce:
> tinkerPop 3.2.6 gremlin:
> {code}
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.spark
> plugin activated: tinkerpop.tinkergraph
> gremlin> graph =
> GraphFactory.open('conf/hadoop/hadoop-grateful-gryo.properties')
> gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
> ==>graphtraversalsource[hadoopgraph[gryoinputformat->gryooutputformat],
> sparkgraphcomputer]
> gremlin> g.V().out().out().count().profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms)% Dur
> =
> GraphStep(vertex,[]) 808
>808 2.02518.35
> VertexStep(OUT,vertex) 8049
>562 4.43040.14
> VertexStep(OUT,edge) 327370
> 7551 4.58141.50
> CountGlobalStep1
> 1 0.001 0.01
> >TOTAL -
> - 11.038-
> gremlin> clock(1){g.V().out().out().count().next() }
> ==>3421.92758
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop issue #734: TINKERPOP-1801: fix profile() timing in OLAP by adding...
Github user artem-aliev commented on the issue: https://github.com/apache/tinkerpop/pull/734 I have fixed test failures. TinkerPopComputer does not call ComputerPorgram.execute methods if spit has no vertices. For example: modern graph has 6 vertices but computer has 8 cores, there will be two empty splits. TraversalVertexProgram use execute step to setup next profiling step, so it is not setup side effects properly for empty splits. So tests did not filed in docker but failed on computer with more then 6 cores. The fix add check that profile side effects were regester properly before using ---
[jira] [Closed] (TINKERPOP-1819) documentation query and description mismatch
[
https://issues.apache.org/jira/browse/TINKERPOP-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1819.
---
Resolution: Fixed
Assignee: stephen mallette
Fix Version/s: 3.3.1
3.2.7
Thanks for reporting this - fixed via:
https://github.com/apache/tinkerpop/commit/909cd9114652dd0a1724deddc8c97bf42c1ea293
> documentation query and description mismatch
>
>
> Key: TINKERPOP-1819
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1819
> Project: TinkerPop
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.3.0
>Reporter: Chandran Anjur Narasimhan
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.7, 3.3.1
>
>
> http://tinkerpop.apache.org/docs/current/reference/
> Section: Graph Traversal Steps->General Steps
> Query: gremlin> g.V().filter {it.get().label() == 'person'} //1
> Explanation (wrong): A filter that only allows the vertex to pass if it has
> an age-property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods
[
https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224829#comment-16224829
]
ASF GitHub Bot commented on TINKERPOP-1752:
---
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/712
Yes it builds, this PR is good to go on my end!
Sorry I forgot to confirm on Friday :/
> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params
> object[] args}} as an argument which allows the user to provide an arbitrary
> number of arguments with any type. While this makes the generation rather
> simple, it doesn't tell the user which arguments are actually valid so users
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users
> something about what kind of values the methods expect. Consider for example
> the following method signatures for the C# step {{AddE}} that are basically a
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[]
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve
> TINKERPOP-1751.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop issue #712: TINKERPOP-1752: Gremlin.Net: Generate completely type-...
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/712 Yes it builds, this PR is good to go on my end! Sorry I forgot to confirm on Friday :/ ---
[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods
[
https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224828#comment-16224828
]
ASF GitHub Bot commented on TINKERPOP-1752:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/712
@jorgebay did the docker build ever finish successfully?
> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params
> object[] args}} as an argument which allows the user to provide an arbitrary
> number of arguments with any type. While this makes the generation rather
> simple, it doesn't tell the user which arguments are actually valid so users
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users
> something about what kind of values the methods expect. Consider for example
> the following method signatures for the C# step {{AddE}} that are basically a
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[]
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve
> TINKERPOP-1751.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop issue #712: TINKERPOP-1752: Gremlin.Net: Generate completely type-...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/712 @jorgebay did the docker build ever finish successfully? ---
[GitHub] tinkerpop issue #738: TINKERPOP-1820 Include Python and .NET GLVs on TravisC...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/738 I see that you used the `-q` option. What happens if there is a failure in native python tests? currently i don't see any output for those, i'm wondering how that will fail when it does. I think it's good to include the GLVs on Travis, but it won't eliminate local builds completely because travis doesn't run integration tests - nor do we want it to probably. This build already takes 20 minutes on Travis which is a reasonably fast feedback from the build server. I don't think we want to lose that. ---
[jira] [Commented] (TINKERPOP-1820) Include Python and .NET GLV tests on TravisCI
[ https://issues.apache.org/jira/browse/TINKERPOP-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224661#comment-16224661 ] ASF GitHub Bot commented on TINKERPOP-1820: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/738 I see that you used the `-q` option. What happens if there is a failure in native python tests? currently i don't see any output for those, i'm wondering how that will fail when it does. I think it's good to include the GLVs on Travis, but it won't eliminate local builds completely because travis doesn't run integration tests - nor do we want it to probably. This build already takes 20 minutes on Travis which is a reasonably fast feedback from the build server. I don't think we want to lose that. > Include Python and .NET GLV tests on TravisCI > - > > Key: TINKERPOP-1820 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1820 > Project: TinkerPop > Issue Type: Test > Components: dotnet, python >Reporter: Jorge Bay > > We can avoid the need of manual test runs by using TravisCI to run both GLVs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1820) Include Python and .NET GLV tests on TravisCI
[ https://issues.apache.org/jira/browse/TINKERPOP-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224540#comment-16224540 ] ASF GitHub Bot commented on TINKERPOP-1820: --- GitHub user jorgebay opened a pull request: https://github.com/apache/tinkerpop/pull/738 TINKERPOP-1820 Include Python and .NET GLVs on TravisCI https://issues.apache.org/jira/browse/TINKERPOP-1820 Run Python and .NET GLV tests on travis CI. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jorgebay/tinkerpop travis-glvs-tp32 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/738.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #738 commit a29d6b803ca8152d20f2ed8204b6fdec7fad9f70 Author: Jorge Bay Gondra Date: 2017-10-30T09:11:51Z Include Python and .NET GLVs on TravisCI > Include Python and .NET GLV tests on TravisCI > - > > Key: TINKERPOP-1820 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1820 > Project: TinkerPop > Issue Type: Test > Components: dotnet, python >Reporter: Jorge Bay > > We can avoid the need of manual test runs by using TravisCI to run both GLVs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #738: TINKERPOP-1820 Include Python and .NET GLVs on ...
GitHub user jorgebay opened a pull request: https://github.com/apache/tinkerpop/pull/738 TINKERPOP-1820 Include Python and .NET GLVs on TravisCI https://issues.apache.org/jira/browse/TINKERPOP-1820 Run Python and .NET GLV tests on travis CI. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jorgebay/tinkerpop travis-glvs-tp32 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/738.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #738 commit a29d6b803ca8152d20f2ed8204b6fdec7fad9f70 Author: Jorge Bay Gondra Date: 2017-10-30T09:11:51Z Include Python and .NET GLVs on TravisCI ---
[jira] [Created] (TINKERPOP-1820) Include Python and .NET GLV tests on TravisCI
Jorge Bay created TINKERPOP-1820: Summary: Include Python and .NET GLV tests on TravisCI Key: TINKERPOP-1820 URL: https://issues.apache.org/jira/browse/TINKERPOP-1820 Project: TinkerPop Issue Type: Test Components: dotnet, python Reporter: Jorge Bay We can avoid the need of manual test runs by using TravisCI to run both GLVs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
CountStrategy and TraversalHelper.replaceStep
Hi,
Whilst optimizing the NotStep I came across what looks to me like a bug
in TraversalHelper.replaceStep or perhaps rather in CountStrategy.
The test below shows the bug.
@Test
public void g_VX1X_repeatXoutX_untilXoutE_count_isX0XX_name() {
Graph graph = TinkerFactory.createModern();
final Traversal traversal1 = graph.traversal()
.V(convertToVertexId(graph, "marko"))
.repeat(__.out())
.until(__.not(__.outE()))
.values("name");
checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
traversal1);
List vertexSteps =
TraversalHelper.getStepsOfAssignableClassRecursively(VertexStep.class,
traversal1.asAdmin());
VertexStep vertexStep = vertexSteps.stream().filter(s ->
s.returnsEdge()).findAny().get();
Assert.assertEquals(EmptyStep.instance(),
vertexStep.getPreviousStep());
final Traversal traversal2 = graph.traversal()
.V(convertToVertexId(graph, "marko"))
.repeat(__.out())
.until(__.outE().count().is(0))
.values("name");
checkResults(Arrays.asList("lop", "lop", "ripple", "vadas"),
traversal2);
vertexSteps =
TraversalHelper.getStepsOfAssignableClassRecursively(VertexStep.class,
traversal2.asAdmin());
vertexStep = vertexSteps.stream().filter(s ->
s.returnsEdge()).findAny().get();
//This fails because the vertexStep's previous step is the
NotStepwhen it should be an EmptyStep.
Assert.assertEquals(EmptyStep.instance(),
vertexStep.getPreviousStep());
}
traversal1 and traversal2 should be the same as the CountStrategy will
replace the __.outE().count().is(0) with __.not(__.outE())
The CountStrategy does what its suppose to do however then it calls
TraversalHelper.replaceStep(prev, new NotStep<>(traversal, inner),
traversal); the traversal's VertexStep gets its previousStep set to the
NotStep. This is because of the way TraversalHelper.replaceStep is
implemented.
I am not sure whether the fix should be in replaceStep or rather in
CountStrategy.
Thanks
Pieter
