[jira] [Commented] (TINKERPOP-3020) Incorrect tests
[
https://issues.apache.org/jira/browse/TINKERPOP-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793769#comment-17793769
]
pieter martin commented on TINKERPOP-3020:
--
Ok yes, I did not even notice its on the empty graph. I'll investigate why its
expecting weight to be a double.
> Incorrect tests
> ---
>
> Key: TINKERPOP-3020
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3020
> Project: TinkerPop
> Issue Type: Test
> Components: test-suite
>Affects Versions: 3.7.1
>Reporter: pieter martin
>Priority: Major
>
> The following tests are incorrectly specified.
> {code:java}
> OptOut...
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_bothE_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_bothE_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_bothE_dedup_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_bothE_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_both_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_both_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_both_dedup_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_both_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_out_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_in_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_out_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_out_name",
> "int should be double"),
> Map.entry("g_VX1X_formatXstrX_byXconstantXhelloXX_byXvaluesXnameXX", "id can
> not be an int"),
> Map.entry("g_withSideEffectXc_created_YX_withSideEffectXm_matchedX_mergeEXlabel_knows_out_marko_in_vadasX_optionXonCreate_selectXcXX_optionXonMatch_sideEffectXpropertiesXweightX_dropX_selectXmXX_exists",
> "int should be double"),
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3020) Incorrect tests
pieter martin created TINKERPOP-3020:
Summary: Incorrect tests
Key: TINKERPOP-3020
URL: https://issues.apache.org/jira/browse/TINKERPOP-3020
Project: TinkerPop
Issue Type: Test
Components: test-suite
Affects Versions: 3.7.1
Reporter: pieter martin
The following tests are incorrectly specified.
{code:java}
OptOut...
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_bothE_weight",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_bothE_weight",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_bothE_dedup_weight",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_bothE_weight",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_both_name",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_both_name",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_both_dedup_name",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_both_name",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_out_name",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_in_name", "int
should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_out_name",
"int should be double"),
Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_out_name",
"int should be double"),
Map.entry("g_VX1X_formatXstrX_byXconstantXhelloXX_byXvaluesXnameXX", "id can
not be an int"),
Map.entry("g_withSideEffectXc_created_YX_withSideEffectXm_matchedX_mergeEXlabel_knows_out_marko_in_vadasX_optionXonCreate_selectXcXX_optionXonMatch_sideEffectXpropertiesXweightX_dropX_selectXmXX_exists",
"int should be double"),
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3019) Refactor package to allow clients to use Java Modules
pieter martin created TINKERPOP-3019:
Summary: Refactor package to allow clients to use Java Modules
Key: TINKERPOP-3019
URL: https://issues.apache.org/jira/browse/TINKERPOP-3019
Project: TinkerPop
Issue Type: Improvement
Components: structure
Reporter: pieter martin
When trying to use both `gremlin-core` and `gremlin-language` in a java modules
build it fails with,
{noformat}
module org.sqlg reads package org.apache.tinkerpop.gremlin.language.grammar
from both gremlin.language and gremlin.core
{noformat}
When building using java modules the following code is needed in
module-info.java
{code:java}
module org.sqlg {
requires gremlin.core;
requires gremlin.language;
requires gremlin.shaded;
}
{code}
Both gremlin-core and gremlin-language have the package
{code:java}
org.apache.tinkerpop.gremlin.language.grammar
{code}
This is called a split package and it not allowed by the java module system.
Seeing as Gremlin.g4 generates into
org.apache.tinkerpop.gremlin.language.grammar I suggest renaming
org.apache.tinkerpop.gremlin.language.grammar to something else in gremlin-core.
On my local machine I renamed
gremlin-core/org.apache.tinkerpop.gremlin.language.grammar to
org.apache.tinkerpop.gremlin.language.grammar2 which resolved the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2998) UnionStep.isStart needs a public getter
pieter martin created TINKERPOP-2998:
Summary: UnionStep.isStart needs a public getter
Key: TINKERPOP-2998
URL: https://issues.apache.org/jira/browse/TINKERPOP-2998
Project: TinkerPop
Issue Type: Improvement
Components: structure
Affects Versions: 3.6.5
Reporter: pieter martin
When replacing steps the replaced step's internal state needs to be accessed.
Currently I am forced to use reflection to access {{UnionStep.isStart}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703141#comment-17703141
]
pieter martin commented on TINKERPOP-2816:
--
Coin.feature g_withStrategiesXSeedStrategyX_V_coinX50X has a similar issue. It
requires order to be applied first.
{code:java}
@GraphComputerVerificationStrategyNotSupported @WithSeedStrategy
Scenario: g_withStrategiesXSeedStrategyX_V_coinX50X
Given the modern graph
And the traversal of
"""
g.withStrategies(new SeedStrategy(seed: 99)).V().coin(0.5)
"""
When iterated to list
Then the result should be unordered
| result |
| v[marko] |
{code}
> Gherkin test issues for implementers
>
>
> Key: TINKERPOP-2816
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2816
> Project: TinkerPop
> Issue Type: Bug
> Components: test-suite
>Affects Versions: 3.6.1
>Reporter: pieter martin
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
> Fix For: 3.7.0, 3.6.2, 3.5.5
>
>
> Sqlg is encountering some issues when running the Gherkin feature tests.
> h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> {code:java}
> Scenario:
> g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> Given the modern graph
> And the traversal of
> """
>
> g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
> """
> When iterated next
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | ripple |
> {code}
> This test assumes an implicit order in the traversal. To fix the test we need
> to add in an {{order().by("name")}}
> {code:java}
> Scenario:
> g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> Given the modern graph
> And the traversal of
> """
> g.V().repeat(__.out().repeat(__.out().order().by("name",
> Order.desc)).times(1)).times(1).limit(1).path().by("name")
> """
> When iterated next
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | ripple |
> {code}
> h2. g_V_both_both_dedup_byXoutE_countX_name
> {code:java}
> Scenario: g_V_both_both_dedup_byXoutE_countX_name
> Given the modern graph
> And the traversal of
> """
> g.V().both().both().dedup().by(__.outE().count()).values("name")
> """
> When iterated to list
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | peter |
> | ripple |
> {code}
> This test assumes the order of {{{}V().both().both(){}}}.
> Unfortunately putting in an {{order().by("name")}} does not help. This is
> because of a second bug where {{TinkerPop}} is rewriting the steps
> incorrectly.
> {code:java}
> @Test
> public void testDedupSteps() {
> final TinkerGraph g = TinkerFactory.createModern();
> GraphTraversal traversal =
> g.traversal().V().both().both().order().by("name",
> Order.asc).dedup().by(__.outE().count()).values("name");
> traversal.hasNext();
> System.out.println(((DefaultGraphTraversal)traversal).getSteps());
> }
> {code}
> This produces,
> {code:java}
> [TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
> VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
> CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
> (null)])]), asc]]), PropertiesStep([name],value)]
> {code}
> For some reason the {{OrderGlobalStep}} is moved to the end, after the
> {{DedupGlobalStep}}
> h2. g_V_playlist_paths
> {code:java}
> Scenario: g_V_playlist_paths
> Given the grateful graph
> And the traversal of
> """
> g.V().has("name", "Bob_Dylan").
> in("sungBy").order().by('name').as("a").
> repeat(__.out().order().by('name').simplePath().from("a")).
> until(__.out("writtenBy").has("name",
> "Johnny_Cash")).limit(1).as("b").
>
> repeat(__.out().order().by('name').as("c").simplePath().from("b").to("c")).
> until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
> path().from("a").unfold().
> project("song", "artists").
> by("name").
> by(__.coalesce(__.out("sungBy",
> "writtenBy").dedup().values("name").order(), __.constant("Unknown")).fold())
> """
> When iterated to list
> Then the result should be unordered
> | result |
> | m[{"song": "CHIMES OF FREEDOM", "artists": ["Bob_Dylan"]}] |
> | m[{"song": "QUEEN JANE", "artists": ["Unknown"]}] |
> | m[{"song": "ALTHEA", "artists": ["Garcia","Hunter"]}] |
> | m[{"song": "BIG RIVER", "artists":
[jira] [Updated] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2816:
-
Description:
Sqlg is encountering some issues when running the Gherkin feature tests.
h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
This test assumes an implicit order in the traversal. To fix the test we need
to add in an {{order().by("name")}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out().order().by("name",
Order.desc)).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
h2. g_V_both_both_dedup_byXoutE_countX_name
{code:java}
Scenario: g_V_both_both_dedup_byXoutE_countX_name
Given the modern graph
And the traversal of
"""
g.V().both().both().dedup().by(__.outE().count()).values("name")
"""
When iterated to list
Then the result should be unordered
| result |
| marko |
| josh |
| peter |
| ripple |
{code}
This test assumes the order of {{{}V().both().both(){}}}.
Unfortunately putting in an {{order().by("name")}} does not help. This is
because of a second bug where {{TinkerPop}} is rewriting the steps incorrectly.
{code:java}
@Test
public void testDedupSteps() {
final TinkerGraph g = TinkerFactory.createModern();
GraphTraversal traversal =
g.traversal().V().both().both().order().by("name",
Order.asc).dedup().by(__.outE().count()).values("name");
traversal.hasNext();
System.out.println(((DefaultGraphTraversal)traversal).getSteps());
}
{code}
This produces,
{code:java}
[TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
(null)])]), asc]]), PropertiesStep([name],value)]
{code}
For some reason the {{OrderGlobalStep}} is moved to the end, after the
{{DedupGlobalStep}}
h2. g_V_playlist_paths
{code:java}
Scenario: g_V_playlist_paths
Given the grateful graph
And the traversal of
"""
g.V().has("name", "Bob_Dylan").
in("sungBy").order().by('name').as("a").
repeat(__.out().order().by('name').simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
repeat(__.out().order().by('name').as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
path().from("a").unfold().
project("song", "artists").
by("name").
by(__.coalesce(__.out("sungBy",
"writtenBy").dedup().values("name").order(), __.constant("Unknown")).fold())
"""
When iterated to list
Then the result should be unordered
| result |
| m[{"song": "CHIMES OF FREEDOM", "artists": ["Bob_Dylan"]}] |
| m[{"song": "QUEEN JANE", "artists": ["Unknown"]}] |
| m[{"song": "ALTHEA", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "BIG RIVER", "artists": ["Johnny_Cash","Weir"]}] |
| m[{"song": "HES GONE", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "CAUTION", "artists": ["Grateful_Dead"]}] |
{code}
This test also assumes `order`. Even though it has
`__.out().order().by('name')` it is the path that needs to be ordered. Ordering
on `name` is not good enough as there are duplicates.
Here is an improved version.
{code:java}
List> result = g.traversal().V().has("name",
"Bob_Dylan").
in("sungBy").order().by("name").as("a").
//repeat(__.out().order().by("name").simplePath().from("a")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()), String::compareTo).simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
//
repeat(__.out().order().by("name").as("c").simplePath().from("b").to("c")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()),
String::compareTo).as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
[jira] [Updated] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2816:
-
Description:
Sqlg is encountering some issues when running the Gherkin feature tests.
h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
This test assumes an implicit order in the traversal. To fix the test we need
to add in an {{order().by("name")}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out().order().by("name",
Order.desc)).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
h2. g_V_both_both_dedup_byXoutE_countX_name
{code:java}
Scenario: g_V_both_both_dedup_byXoutE_countX_name
Given the modern graph
And the traversal of
"""
g.V().both().both().dedup().by(__.outE().count()).values("name")
"""
When iterated to list
Then the result should be unordered
| result |
| marko |
| josh |
| peter |
| ripple |
{code}
This test assumes the order of {{{}V().both().both(){}}}.
Unfortunately putting in an {{order().by("name")}} does not help. This is
because of a second bug where {{TinkerPop}} is rewriting the steps incorrectly.
{code:java}
@Test
public void testDedupSteps() {
final TinkerGraph g = TinkerFactory.createModern();
GraphTraversal traversal =
g.traversal().V().both().both().order().by("name",
Order.asc).dedup().by(__.outE().count()).values("name");
traversal.hasNext();
System.out.println(((DefaultGraphTraversal)traversal).getSteps());
}
{code}
This produces,
{code:java}
[TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
(null)])]), asc]]), PropertiesStep([name],value)]
{code}
For some reason the {{OrderGlobalStep}} is moved to the end, after the
{{DedupGlobalStep}}
h2. g_V_playlist_paths
{code:java}
Scenario: g_V_playlist_paths
Given the grateful graph
And the traversal of
"""
g.V().has("name", "Bob_Dylan").
in("sungBy").order().by('name').as("a").
repeat(__.out().order().by('name').simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
repeat(__.out().order().by('name').as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
path().from("a").unfold().
project("song", "artists").
by("name").
by(__.coalesce(__.out("sungBy",
"writtenBy").dedup().values("name").order(), __.constant("Unknown")).fold())
"""
When iterated to list
Then the result should be unordered
| result |
| m[{"song": "CHIMES OF FREEDOM", "artists": ["Bob_Dylan"]}] |
| m[{"song": "QUEEN JANE", "artists": ["Unknown"]}] |
| m[{"song": "ALTHEA", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "BIG RIVER", "artists": ["Johnny_Cash","Weir"]}] |
| m[{"song": "HES GONE", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "CAUTION", "artists": ["Grateful_Dead"]}] |
{code}
This test also assumes `order`. Even though it has
`__.out().order().by('name')` it is the path that needs to be ordered. Ordering
on `name` is not good enough as there are duplicates.
Here is an improved version.
{code:java}
List> result = g.traversal().V().has("name",
"Bob_Dylan").
in("sungBy").order().by("name").as("a").
//repeat(__.out().order().by("name").simplePath().from("a")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()), String::compareTo).simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
//
repeat(__.out().order().by("name").as("c").simplePath().from("b").to("c")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()),
String::compareTo).as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
[jira] [Commented] (TINKERPOP-2804) gherkin feature files should be on the classpath
[
https://issues.apache.org/jira/browse/TINKERPOP-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626188#comment-17626188
]
pieter martin commented on TINKERPOP-2804:
--
The io files need to be available on the test scoped classpath. Currently they
are referring to *../data/*
{code:java}
java.lang.RuntimeException: java.lang.IllegalStateException:
../data/tinkerpop-modern.kryo does not exist
at
org.apache.tinkerpop.gremlin.features.StepDefinition.assertThatNoErrorWasThrown(StepDefinition.java:405)
{code}
> gherkin feature files should be on the classpath
>
>
> Key: TINKERPOP-2804
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2804
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.6.0
>Reporter: pieter martin
>Priority: Minor
>
> Currently implementers needs to access the gherkin features on disc.
> It should be available on the classpath.
> i.e. gremlin-test/features should be inside the jar
> This will allow,
> @CucumberOptions(features = { "classpath:/gremlin-test/features" })
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2816:
-
Description:
Sqlg is encountering some issues when running the Gherkin feature tests.
h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
This test assumes an implicit order in the traversal. To fix the test we need
to add in an {{order().by("name")}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out().order().by("name",
Order.desc)).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
h2. g_V_both_both_dedup_byXoutE_countX_name
{code:java}
Scenario: g_V_both_both_dedup_byXoutE_countX_name
Given the modern graph
And the traversal of
"""
g.V().both().both().dedup().by(__.outE().count()).values("name")
"""
When iterated to list
Then the result should be unordered
| result |
| marko |
| josh |
| peter |
| ripple |
{code}
This test assumes the order of {{{}V().both().both(){}}}.
Unfortunately putting in an {{order().by("name")}} does not help. This is
because of a second bug where {{TinkerPop}} is rewriting the steps incorrectly.
{code:java}
@Test
public void testDedupSteps() {
final TinkerGraph g = TinkerFactory.createModern();
GraphTraversal traversal =
g.traversal().V().both().both().order().by("name",
Order.asc).dedup().by(__.outE().count()).values("name");
traversal.hasNext();
System.out.println(((DefaultGraphTraversal)traversal).getSteps());
}
{code}
This produces,
{code:java}
[TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
(null)])]), asc]]), PropertiesStep([name],value)]
{code}
For some reason the {{OrderGlobalStep}} is moved to the end, after the
{{DedupGlobalStep}}
h2. g_V_playlist_paths
{code:java}
Scenario: g_V_playlist_paths
Given the grateful graph
And the traversal of
"""
g.V().has("name", "Bob_Dylan").
in("sungBy").order().by('name').as("a").
repeat(__.out().order().by('name').simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
repeat(__.out().order().by('name').as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
path().from("a").unfold().
project("song", "artists").
by("name").
by(__.coalesce(__.out("sungBy",
"writtenBy").dedup().values("name").order(), __.constant("Unknown")).fold())
"""
When iterated to list
Then the result should be unordered
| result |
| m[{"song": "CHIMES OF FREEDOM", "artists": ["Bob_Dylan"]}] |
| m[{"song": "QUEEN JANE", "artists": ["Unknown"]}] |
| m[{"song": "ALTHEA", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "BIG RIVER", "artists": ["Johnny_Cash","Weir"]}] |
| m[{"song": "HES GONE", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "CAUTION", "artists": ["Grateful_Dead"]}] |
{code}
This test also assumes `order`. Even though it has
`__.out().order().by('name')` it is the path that needs to be ordered. Ordering
on `name` is not good enough as there are duplicates.
Here is an improved version.
{code:java}
List> result = g.traversal().V().has("name",
"Bob_Dylan").
in("sungBy").order().by("name").as("a").
//repeat(__.out().order().by("name").simplePath().from("a")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()), String::compareTo).simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
//
repeat(__.out().order().by("name").as("c").simplePath().from("b").to("c")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()),
String::compareTo).as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
[jira] [Updated] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2816:
-
Description:
Sqlg is encountering some issues when running the Gherkin feature tests.
h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
This test assumes an implicit order in the traversal. To fix the test we need
to add in an {{order().by("name")}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out().order().by("name",
Order.desc)).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
h2. g_V_both_both_dedup_byXoutE_countX_name
{code:java}
Scenario: g_V_both_both_dedup_byXoutE_countX_name
Given the modern graph
And the traversal of
"""
g.V().both().both().dedup().by(__.outE().count()).values("name")
"""
When iterated to list
Then the result should be unordered
| result |
| marko |
| josh |
| peter |
| ripple |
{code}
This test assumes the order of {{{}V().both().both(){}}}.
Unfortunately putting in an {{order().by("name")}} does not help. This is
because of a second bug where {{TinkerPop}} is rewriting the steps incorrectly.
{code:java}
@Test
public void testDedupSteps() {
final TinkerGraph g = TinkerFactory.createModern();
GraphTraversal traversal =
g.traversal().V().both().both().order().by("name",
Order.asc).dedup().by(__.outE().count()).values("name");
traversal.hasNext();
System.out.println(((DefaultGraphTraversal)traversal).getSteps());
}
{code}
This produces,
{code:java}
[TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
(null)])]), asc]]), PropertiesStep([name],value)]
{code}
For some reason the {{OrderGlobalStep}} is moved to the end, after the
{{DedupGlobalStep}}
h2. g_V_playlist_paths
{code:java}
Scenario: g_V_playlist_paths
Given the grateful graph
And the traversal of
"""
g.V().has("name", "Bob_Dylan").
in("sungBy").order().by('name').as("a").
repeat(__.out().order().by('name').simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
repeat(__.out().order().by('name').as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
path().from("a").unfold().
project("song", "artists").
by("name").
by(__.coalesce(__.out("sungBy",
"writtenBy").dedup().values("name").order(), __.constant("Unknown")).fold())
"""
When iterated to list
Then the result should be unordered
| result |
| m[{"song": "CHIMES OF FREEDOM", "artists": ["Bob_Dylan"]}] |
| m[{"song": "QUEEN JANE", "artists": ["Unknown"]}] |
| m[{"song": "ALTHEA", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "BIG RIVER", "artists": ["Johnny_Cash","Weir"]}] |
| m[{"song": "HES GONE", "artists": ["Garcia","Hunter"]}] |
| m[{"song": "CAUTION", "artists": ["Grateful_Dead"]}] |
{code}
This test also assumes `order`. Even though it has
`__.out().order().by('name')` it is the path that needs to be ordered. Ordering
on `name` is not good enough as there are duplicates.
Here is an improved version.
{code:java}
List> result = g.traversal().V().has("name",
"Bob_Dylan").
in("sungBy").order().by("name").as("a").
//repeat(__.out().order().by("name").simplePath().from("a")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()), String::compareTo).simplePath().from("a")).
until(__.out("writtenBy").has("name",
"Johnny_Cash")).limit(1).as("b").
//
repeat(__.out().order().by("name").as("c").simplePath().from("b").to("c")).
repeat(__.out().order().by(__.path().by("name").map(pathTraverser ->
pathTraverser.get().toString()),
String::compareTo).as("c").simplePath().from("b").to("c")).
until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
[jira] [Updated] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2816:
-
Description:
Sqlg is encountering some issues when running the Gherkin feature tests.
h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
This test assumes an implicit order in the traversal. To fix the test we need
to add in an {{order().by("name")}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out().order().by("name",
Order.desc)).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
h2. g_V_both_both_dedup_byXoutE_countX_name
{code:java}
Scenario: g_V_both_both_dedup_byXoutE_countX_name
Given the modern graph
And the traversal of
"""
g.V().both().both().dedup().by(__.outE().count()).values("name")
"""
When iterated to list
Then the result should be unordered
| result |
| marko |
| josh |
| peter |
| ripple |
{code}
This test assumes the order of {{{}V().both().both(){}}}.
Unfortunately putting in an {{order().by("name")}} does not help. This is
because of a second bug where {{TinkerPop}} is rewriting the steps incorrectly.
{code:java}
@Test
public void testDedupSteps() {
final TinkerGraph g = TinkerFactory.createModern();
GraphTraversal traversal =
g.traversal().V().both().both().order().by("name",
Order.asc).dedup().by(__.outE().count()).values("name");
traversal.hasNext();
System.out.println(((DefaultGraphTraversal)traversal).getSteps());
}
{code}
This produces,
{code:java}
[TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
(null)])]), asc]]), PropertiesStep([name],value)]
{code}
For some reason the {{OrderGlobalStep}} is moved to the end, after the
{{DedupGlobalStep}}
was:
Sqlg is encountering some issues when running the Gherkin feature tests.
* {{g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
This test assumes an implicit order in the traversal. To fix the test we need
to add in an {{order().by("name")}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out().order().by("name",
Order.desc)).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
* {{g_V_both_both_dedup_byXoutE_countX_name}}
{code:java}
Scenario: g_V_both_both_dedup_byXoutE_countX_name
Given the modern graph
And the traversal of
"""
g.V().both().both().dedup().by(__.outE().count()).values("name")
"""
When iterated to list
Then the result should be unordered
| result |
| marko |
| josh |
| peter |
| ripple |
{code}
This test assumes the order of {{V().both().both()}}.
Unfortunately putting in an {{order().by("name")}} does not help. This is
because of a second bug where {{TinkerPop}} is rewriting the steps incorrectly.
{code:java}
final TinkerGraph g = TinkerFactory.createModern();
GraphTraversal traversal =
g.traversal().V().both().both().order().by("name",
Order.asc).dedup().by(__.outE().count()).values("name");
while (traversal.hasNext()) {
System.out.println(((DefaultGraphTraversal)traversal).getSteps());
}
{code}
This produces,
{code:java}
[TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
[jira] [Created] (TINKERPOP-2816) Gherkin test issues for implementers
pieter martin created TINKERPOP-2816:
Summary: Gherkin test issues for implementers
Key: TINKERPOP-2816
URL: https://issues.apache.org/jira/browse/TINKERPOP-2816
Project: TinkerPop
Issue Type: Bug
Components: test-suite
Affects Versions: 3.6.1
Reporter: pieter martin
Sqlg is encountering some issues when running the Gherkin feature tests.
* {{g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
This test assumes an implicit order in the traversal. To fix the test we need
to add in an {{order().by("name")}}
{code:java}
Scenario: g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
Given the modern graph
And the traversal of
"""
g.V().repeat(__.out().repeat(__.out().order().by("name",
Order.desc)).times(1)).times(1).limit(1).path().by("name")
"""
When iterated next
Then the result should be unordered
| result |
| marko |
| josh |
| ripple |
{code}
* {{g_V_both_both_dedup_byXoutE_countX_name}}
{code:java}
Scenario: g_V_both_both_dedup_byXoutE_countX_name
Given the modern graph
And the traversal of
"""
g.V().both().both().dedup().by(__.outE().count()).values("name")
"""
When iterated to list
Then the result should be unordered
| result |
| marko |
| josh |
| peter |
| ripple |
{code}
This test assumes the order of {{V().both().both()}}.
Unfortunately putting in an {{order().by("name")}} does not help. This is
because of a second bug where {{TinkerPop}} is rewriting the steps incorrectly.
{code:java}
final TinkerGraph g = TinkerFactory.createModern();
GraphTraversal traversal =
g.traversal().V().both().both().order().by("name",
Order.asc).dedup().by(__.outE().count()).values("name");
while (traversal.hasNext()) {
System.out.println(((DefaultGraphTraversal)traversal).getSteps());
}
{code}
This produces,
{code:java}
[TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
(null)])]), asc]]), PropertiesStep([name],value)]
{code}
For some reason the {{OrderGlobalStep}} is moved to the end, after the
{{DedupGlobalStep}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2805) Change of semantics between 3.5 and 3.6
[
https://issues.apache.org/jira/browse/TINKERPOP-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2805:
-
Description:
{code:java}
@Test
public void test() {
final TinkerGraph sqlgGraph = TinkerGraph.open();
Vertex a1 = sqlgGraph.addVertex(T.label, "A", "name", "a1");
Vertex a2 = sqlgGraph.addVertex(T.label, "A", "name", "a2");
Vertex a3 = sqlgGraph.addVertex(T.label, "A", "name", "a3");
Vertex b1 = sqlgGraph.addVertex(T.label, "B", "name", "b1");
Vertex b2 = sqlgGraph.addVertex(T.label, "B", "name", "b2");
Vertex b3 = sqlgGraph.addVertex(T.label, "B", "name", "b3");
a1.addEdge("ab", b1);
a2.addEdge("ab", b2);
a3.addEdge("ab", b3);
List> result = sqlgGraph.traversal().V().as("a")
.out().as("a")
.in().as("a")
.select(Pop.all, "a", "a", "a")
.toList();
assertEquals(3, result.size());
}
{code}
On 3.5 this test returned 3, on 3.6 it returns 0.
was:
{{
@Test
public void test() {
final TinkerGraph sqlgGraph = TinkerGraph.open();
Vertex a1 = sqlgGraph.addVertex(T.label, "A", "name", "a1");
Vertex a2 = sqlgGraph.addVertex(T.label, "A", "name", "a2");
Vertex a3 = sqlgGraph.addVertex(T.label, "A", "name", "a3");
Vertex b1 = sqlgGraph.addVertex(T.label, "B", "name", "b1");
Vertex b2 = sqlgGraph.addVertex(T.label, "B", "name", "b2");
Vertex b3 = sqlgGraph.addVertex(T.label, "B", "name", "b3");
a1.addEdge("ab", b1);
a2.addEdge("ab", b2);
a3.addEdge("ab", b3);
List> result = sqlgGraph.traversal().V().as("a")
.out().as("a")
.in().as("a")
.select(Pop.all, "a", "a", "a")
.toList();
assertEquals(3, result.size());
}
}}
On 3.5 this test returned 3, on 3.6 it returns 0.
> Change of semantics between 3.5 and 3.6
> ---
>
> Key: TINKERPOP-2805
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2805
> Project: TinkerPop
> Issue Type: Bug
>Reporter: pieter martin
>Priority: Major
>
> {code:java}
> @Test
> public void test() {
> final TinkerGraph sqlgGraph = TinkerGraph.open();
> Vertex a1 = sqlgGraph.addVertex(T.label, "A", "name", "a1");
> Vertex a2 = sqlgGraph.addVertex(T.label, "A", "name", "a2");
> Vertex a3 = sqlgGraph.addVertex(T.label, "A", "name", "a3");
> Vertex b1 = sqlgGraph.addVertex(T.label, "B", "name", "b1");
> Vertex b2 = sqlgGraph.addVertex(T.label, "B", "name", "b2");
> Vertex b3 = sqlgGraph.addVertex(T.label, "B", "name", "b3");
> a1.addEdge("ab", b1);
> a2.addEdge("ab", b2);
> a3.addEdge("ab", b3);
> List> result = sqlgGraph.traversal().V().as("a")
> .out().as("a")
> .in().as("a")
> .select(Pop.all, "a", "a", "a")
> .toList();
> assertEquals(3, result.size());
> }
> {code}
> On 3.5 this test returned 3, on 3.6 it returns 0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2805) Change of semantics between 3.5 and 3.6
[
https://issues.apache.org/jira/browse/TINKERPOP-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2805:
-
Description:
{{
@Test
public void test() {
final TinkerGraph sqlgGraph = TinkerGraph.open();
Vertex a1 = sqlgGraph.addVertex(T.label, "A", "name", "a1");
Vertex a2 = sqlgGraph.addVertex(T.label, "A", "name", "a2");
Vertex a3 = sqlgGraph.addVertex(T.label, "A", "name", "a3");
Vertex b1 = sqlgGraph.addVertex(T.label, "B", "name", "b1");
Vertex b2 = sqlgGraph.addVertex(T.label, "B", "name", "b2");
Vertex b3 = sqlgGraph.addVertex(T.label, "B", "name", "b3");
a1.addEdge("ab", b1);
a2.addEdge("ab", b2);
a3.addEdge("ab", b3);
List> result = sqlgGraph.traversal().V().as("a")
.out().as("a")
.in().as("a")
.select(Pop.all, "a", "a", "a")
.toList();
assertEquals(3, result.size());
}
}}
On 3.5 this test returned 3, on 3.6 it returns 0.
was:
{{@Test
public void test() {
final TinkerGraph sqlgGraph = TinkerGraph.open();
Vertex a1 = sqlgGraph.addVertex(T.label, "A", "name", "a1");
Vertex a2 = sqlgGraph.addVertex(T.label, "A", "name", "a2");
Vertex a3 = sqlgGraph.addVertex(T.label, "A", "name", "a3");
Vertex b1 = sqlgGraph.addVertex(T.label, "B", "name", "b1");
Vertex b2 = sqlgGraph.addVertex(T.label, "B", "name", "b2");
Vertex b3 = sqlgGraph.addVertex(T.label, "B", "name", "b3");
a1.addEdge("ab", b1);
a2.addEdge("ab", b2);
a3.addEdge("ab", b3);
List> result = sqlgGraph.traversal().V().as("a")
.out().as("a")
.in().as("a")
.select(Pop.all, "a", "a", "a")
.toList();
assertEquals(3, result.size());
}}}
On 3.5 this test returned 3, on 3.6 it returns 0.
> Change of semantics between 3.5 and 3.6
> ---
>
> Key: TINKERPOP-2805
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2805
> Project: TinkerPop
> Issue Type: Bug
>Reporter: pieter martin
>Priority: Major
>
> {{
> @Test
> public void test() {
> final TinkerGraph sqlgGraph = TinkerGraph.open();
> Vertex a1 = sqlgGraph.addVertex(T.label, "A", "name", "a1");
> Vertex a2 = sqlgGraph.addVertex(T.label, "A", "name", "a2");
> Vertex a3 = sqlgGraph.addVertex(T.label, "A", "name", "a3");
> Vertex b1 = sqlgGraph.addVertex(T.label, "B", "name", "b1");
> Vertex b2 = sqlgGraph.addVertex(T.label, "B", "name", "b2");
> Vertex b3 = sqlgGraph.addVertex(T.label, "B", "name", "b3");
> a1.addEdge("ab", b1);
> a2.addEdge("ab", b2);
> a3.addEdge("ab", b3);
> List> result = sqlgGraph.traversal().V().as("a")
> .out().as("a")
> .in().as("a")
> .select(Pop.all, "a", "a", "a")
> .toList();
> assertEquals(3, result.size());
> }
> }}
> On 3.5 this test returned 3, on 3.6 it returns 0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2805) Change of semantics between 3.5 and 3.6
pieter martin created TINKERPOP-2805:
Summary: Change of semantics between 3.5 and 3.6
Key: TINKERPOP-2805
URL: https://issues.apache.org/jira/browse/TINKERPOP-2805
Project: TinkerPop
Issue Type: Bug
Reporter: pieter martin
{{@Test
public void test() {
final TinkerGraph sqlgGraph = TinkerGraph.open();
Vertex a1 = sqlgGraph.addVertex(T.label, "A", "name", "a1");
Vertex a2 = sqlgGraph.addVertex(T.label, "A", "name", "a2");
Vertex a3 = sqlgGraph.addVertex(T.label, "A", "name", "a3");
Vertex b1 = sqlgGraph.addVertex(T.label, "B", "name", "b1");
Vertex b2 = sqlgGraph.addVertex(T.label, "B", "name", "b2");
Vertex b3 = sqlgGraph.addVertex(T.label, "B", "name", "b3");
a1.addEdge("ab", b1);
a2.addEdge("ab", b2);
a3.addEdge("ab", b3);
List> result = sqlgGraph.traversal().V().as("a")
.out().as("a")
.in().as("a")
.select(Pop.all, "a", "a", "a")
.toList();
assertEquals(3, result.size());
}}}
On 3.5 this test returned 3, on 3.6 it returns 0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2804) gherkin feature files should be on the classpath
[
https://issues.apache.org/jira/browse/TINKERPOP-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-2804:
-
Description:
Currently implementers needs to access the gherkin features on disc.
It should be available on the classpath.
i.e. gremlin-test/features should be inside the jar
This will allow,
@CucumberOptions(features = { "classpath:/gremlin-test/features" })
was:
Currently implementers needs to access the gherkin features on disc.
It should be available on the classpath.
i.e. `gremlin-test/features` should be inside the jar
> gherkin feature files should be on the classpath
>
>
> Key: TINKERPOP-2804
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2804
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.6.0
>Reporter: pieter martin
>Priority: Minor
>
> Currently implementers needs to access the gherkin features on disc.
> It should be available on the classpath.
> i.e. gremlin-test/features should be inside the jar
> This will allow,
> @CucumberOptions(features = { "classpath:/gremlin-test/features" })
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2804) gherkin feature files should be on the classpath
pieter martin created TINKERPOP-2804: Summary: gherkin feature files should be on the classpath Key: TINKERPOP-2804 URL: https://issues.apache.org/jira/browse/TINKERPOP-2804 Project: TinkerPop Issue Type: Improvement Components: test-suite Affects Versions: 3.6.0 Reporter: pieter martin Currently implementers needs to access the gherkin features on disc. It should be available on the classpath. i.e. `gremlin-test/features` should be inside the jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-1616) Strengthen semantics around lazy iteration and graph modifications
[
https://issues.apache.org/jira/browse/TINKERPOP-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384549#comment-16384549
]
pieter martin commented on TINKERPOP-1616:
--
I do have any {{OptOut}} tests for this as such. The test that originally
highlighted the issue is
{{EdgeTest.shouldNotHaveAConcurrentModificationExceptionWhenIteratingAndRemovingAddingEdges}}
However the issue remains. TinkerPop is encouraging using inline {{addV}} and
{{addE}} but as {{gremlin}} does not specify iteration order nor iteration
depth/laziness a user will never know exactly what the result will be. I do not
think this can be left to provider documentation. The language needs to be
exactly specified. The same query can not have different outcomes on different
providers.
{code:java}
@Test
public void testLazy1AddE() {
final TinkerGraph g = TinkerGraph.open();
final Vertex a1 = g.addVertex(T.label, "A");
final Vertex b1 = g.addVertex(T.label, "B");
final Vertex c1 = g.addVertex(T.label, "C");
a1.addEdge("ab", b1);
a1.addEdge("ac", c1);
GraphTraversal t = g.traversal().V(a1).both().addE("ab").from(a1).to(b1);
List edges = t.toList();
System.out.println(edges.size());
}
{code}
Here is the same example again but this time using inline {{addE}}
For TinkerGraph the result is 2. This is bacause TinkerGraph's implementation
behaves as though there is a {{barrier}} step before the {{addE}}.
For Sqlg the result is 3. Sqlg is more lazy than TinkerGraph and by the time
the second {{both}} iteration happens it reads the previously added {{edge}}.
Perhaps the default should be to add in a {{barrier}} step to all modification
steps?
> Strengthen semantics around lazy iteration and graph modifications
> --
>
> Key: TINKERPOP-1616
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1616
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.3
>Reporter: pieter martin
>Assignee: stephen mallette
>Priority: Major
>
> The investigation started with the a bothE query where Sqlg returned
> different results to TinkerGraph
> {code}
> @Test
> public void testLazy1() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).bothE().forEachRemaining(edge -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> For this query TinkerGraph returns 2 and passes.
> Sqlg however returns 3. The reason being that it lazily iterates the out()
> first and then the in().
> The following gremlin is the same but using a union(out(), in()) instead of
> bothE()
> {code}
> @Test
> public void testLazy2() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).union(__.outE(), __.inE()).forEachRemaining(edge
> -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> In this case TinkerGraph returns 4 and Sqlg 6
> TinkerGraph returns 4 as it first walks the 2 out edges and adds 2 in edges
> which it sees when traversing the in().
> Sqlg return 6 as it lazier than TinkerGraph.
> It first walks the "ac" out edge and adds in the 2 edges.
> Then walks "ab" and gets 2 edges. The original and the one added previously.
> It then walks "ac" in and gets 3 edges as 3 has been added so far.
> All and all 6.
> I am not sure whats the expected semantics. Sqlg is lazier than TinkerGraph
> but not completely lazy either as it depends more on the meta data and number
> of queries it needs to execute to walk a particular gremlin query.
> I am somewhat of the opinion that without enforcing a eager iteration when
> modifying a graph the semantics will be different for different implementors.
> For Sqlg at least it will be hard for clients to predict the behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1832) TraversalHelper.replaceStep sets previousStep to the wrong step
pieter martin created TINKERPOP-1832:
Summary: TraversalHelper.replaceStep sets previousStep to the
wrong step
Key: TINKERPOP-1832
URL: https://issues.apache.org/jira/browse/TINKERPOP-1832
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.3.0
Reporter: pieter martin
The bug is described over
[here|http://mail-archives.apache.org/mod_mbox/tinkerpop-dev/201710.mbox/browser]
I have tested [~dkuppitz] fix for it and all seems well.
{code:java}
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);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1822) Repeat should depth first search
[
https://issues.apache.org/jira/browse/TINKERPOP-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16233681#comment-16233681
]
pieter martin commented on TINKERPOP-1822:
--
Perhaps this ticket could be generalized to all traversals.
My understanding is that TinkerPop has no specified semantics regarding DFS or
BFS. Traversals can be optimized and subtly change what a user might have
expected. As this is unspecified semantics different implementation can also
have different behavior based on their strategies. Even on TinkerGraph I'd say
most users can not upfront tell exactly how any particular traversal may be
optimized. Steps rewritten, barriers injected etc. If users want to have
reliable DFS/BFS semantics it should be specified.
Perhaps TinkerPop needs a first class notion of {{DFS/BFS/NONE}} which can be
properly specified and tested.
The default would be {{NONE}} like it is now with the implementation free to
optimize it in any way it sees fit.
How about using the existing {{OrderStep}}?
{{repeat(out().order(DFS))}}
> Repeat should depth first search
>
>
> Key: TINKERPOP-1822
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1822
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Robert Dale
>Priority: Major
>
> Perhaps optionally.
> See also:
> * https://groups.google.com/forum/#!topic/gremlin-users/gLSLxH_K-wE
> * https://github.com/apache/tinkerpop/pull/715
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1822) Repeat should depth first search
[ https://issues.apache.org/jira/browse/TINKERPOP-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226989#comment-16226989 ] pieter martin commented on TINKERPOP-1822: -- Is this a nice to have, and change to the default behaviour or is to be part of the expected semantics of RepeatStep? Will there be test cases to validate that the traversal was executed depth first? > Repeat should depth first search > > > Key: TINKERPOP-1822 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1822 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.3.0, 3.2.6 >Reporter: Robert Dale > > Perhaps optionally. > See also: > * https://groups.google.com/forum/#!topic/gremlin-users/gLSLxH_K-wE > * https://github.com/apache/tinkerpop/pull/715 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1691) Some EventStrategyProcessTest assume element state is synced in memory
[
https://issues.apache.org/jira/browse/TINKERPOP-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060414#comment-16060414
]
pieter martin commented on TINKERPOP-1691:
--
Yes thanks,
VOTE +1
> Some EventStrategyProcessTest assume element state is synced in memory
> --
>
> Key: TINKERPOP-1691
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1691
> Project: TinkerPop
> Issue Type: Bug
> Components: test-suite
>Affects Versions: 3.2.5
>Reporter: pieter martin
>Priority: Minor
>
> The following 4 tests assumes that the element variable is updated in memory.
> {{EventStrategyProcessTest.shouldDetachVertexPropertyWhenRemoved}}
> {{EventStrategyProcessTest.shouldDetachPropertyOfEdgeWhenNew}}
> {{EventStrategyProcessTest.shouldDetachPropertyOfEdgeWhenRemoved}}
> {{EventStrategyProcessTest.shouldDetachVertexPropertyWhenNew}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TINKERPOP-1691) Some EventStrategyProcessTest assume element state is synced in memory
pieter martin created TINKERPOP-1691:
Summary: Some EventStrategyProcessTest assume element state is
synced in memory
Key: TINKERPOP-1691
URL: https://issues.apache.org/jira/browse/TINKERPOP-1691
Project: TinkerPop
Issue Type: Bug
Components: test-suite
Affects Versions: 3.2.5
Reporter: pieter martin
Priority: Minor
The following 4 tests assumes that the element variable is updated in memory.
{{EventStrategyProcessTest.shouldDetachVertexPropertyWhenRemoved}}
{{EventStrategyProcessTest.shouldDetachPropertyOfEdgeWhenNew}}
{{EventStrategyProcessTest.shouldDetachPropertyOfEdgeWhenRemoved}}
{{EventStrategyProcessTest.shouldDetachVertexPropertyWhenNew}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1681) Multiple hasId's are or'd into GraphStep
[
https://issues.apache.org/jira/browse/TINKERPOP-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027922#comment-16027922
]
pieter martin commented on TINKERPOP-1681:
--
Just to check does your fix also work for,
{noformat}
final TinkerGraph graph = TinkerGraph.open();
Vertex a = graph.addVertex(T.label, "A");
Vertex b = graph.addVertex(T.label, "B");
List vertices = graph.traversal().V(a.id()).hasId(b.id()).toList();
Assert.assertTrue(vertices.isEmpty());
{noformat}
Regarding {{g.V().not(identity())}} it for sure is bad as {{not(identity())}}
is not the kind of thing that Sqlg at least, even tries to optimize.
> Multiple hasId's are or'd into GraphStep
>
>
> Key: TINKERPOP-1681
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1681
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> From the dev mailing list:
> {noformat}
> @Test
> public void testHasId() {
> final TinkerGraph graph = TinkerGraph.open();
> Vertex a = graph.addVertex(T.label, "A");
> Vertex b = graph.addVertex(T.label, "B");
> List vertices =
> graph.traversal().V().hasId(a.id()).hasId(b.id()).toList();
> Assert.assertTrue(vertices.isEmpty());
> }
> {noformat}
> The test fails as the both vertices are returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882966#comment-15882966
]
pieter martin commented on TINKERPOP-1639:
--
Another operation to think about is casting.
It is often the case that when the data is loaded the proper type is not known
and the property is captured as a `String`. Later an analyst or whoever
actually understands the data can cast it to the proper type and do further
manipulations on it.
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1616) Strengthen semantics around lazy iteration and graph modifications
[
https://issues.apache.org/jira/browse/TINKERPOP-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP-1616:
-
Summary: Strengthen semantics around lazy iteration and graph modifications
(was: Strengthen semantics around lizy iteration and graph modifications)
> Strengthen semantics around lazy iteration and graph modifications
> --
>
> Key: TINKERPOP-1616
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1616
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.2.3
>Reporter: pieter martin
>
> The investigation started with the a bothE query where Sqlg returned
> different results to TinkerGraph
> {code}
> @Test
> public void testLazy1() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).bothE().forEachRemaining(edge -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> For this query TinkerGraph returns 2 and passes.
> Sqlg however returns 3. The reason being that it lazily iterates the out()
> first and then the in().
> The following gremlin is the same but using a union(out(), in()) instead of
> bothE()
> {code}
> @Test
> public void testLazy2() {
> final TinkerGraph graph = TinkerGraph.open();
> final Vertex a1 = graph.addVertex(T.label, "A");
> final Vertex b1 = graph.addVertex(T.label, "B");
> final Vertex c1 = graph.addVertex(T.label, "C");
> a1.addEdge("ab", b1);
> a1.addEdge("ac", c1);
> AtomicInteger count = new AtomicInteger(0);
> graph.traversal().V(a1).union(__.outE(), __.inE()).forEachRemaining(edge
> -> {
> a1.addEdge("ab", b1);
> c1.addEdge("ac", a1);
> count.getAndIncrement();
> });
> Assert.assertEquals(2, count.get());
> }
> {code}
> In this case TinkerGraph returns 4 and Sqlg 6
> TinkerGraph returns 4 as it first walks the 2 out edges and adds 2 in edges
> which it sees when traversing the in().
> Sqlg return 6 as it lazier than TinkerGraph.
> It first walks the "ac" out edge and adds in the 2 edges.
> Then walks "ab" and gets 2 edges. The original and the one added previously.
> It then walks "ac" in and gets 3 edges as 3 has been added so far.
> All and all 6.
> I am not sure whats the expected semantics. Sqlg is lazier than TinkerGraph
> but not completely lazy either as it depends more on the meta data and number
> of queries it needs to execute to walk a particular gremlin query.
> I am somewhat of the opinion that without enforcing a eager iteration when
> modifying a graph the semantics will be different for different implementors.
> For Sqlg at least it will be hard for clients to predict the behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1616) Strengthen semantics around lizy iteration and graph modifications
pieter martin created TINKERPOP-1616:
Summary: Strengthen semantics around lizy iteration and graph
modifications
Key: TINKERPOP-1616
URL: https://issues.apache.org/jira/browse/TINKERPOP-1616
Project: TinkerPop
Issue Type: Improvement
Components: structure
Affects Versions: 3.2.3
Reporter: pieter martin
The investigation started with the a bothE query where Sqlg returned different
results to TinkerGraph
{code}
@Test
public void testLazy1() {
final TinkerGraph graph = TinkerGraph.open();
final Vertex a1 = graph.addVertex(T.label, "A");
final Vertex b1 = graph.addVertex(T.label, "B");
final Vertex c1 = graph.addVertex(T.label, "C");
a1.addEdge("ab", b1);
a1.addEdge("ac", c1);
AtomicInteger count = new AtomicInteger(0);
graph.traversal().V(a1).bothE().forEachRemaining(edge -> {
a1.addEdge("ab", b1);
c1.addEdge("ac", a1);
count.getAndIncrement();
});
Assert.assertEquals(2, count.get());
}
{code}
For this query TinkerGraph returns 2 and passes.
Sqlg however returns 3. The reason being that it lazily iterates the out()
first and then the in().
The following gremlin is the same but using a union(out(), in()) instead of
bothE()
{code}
@Test
public void testLazy2() {
final TinkerGraph graph = TinkerGraph.open();
final Vertex a1 = graph.addVertex(T.label, "A");
final Vertex b1 = graph.addVertex(T.label, "B");
final Vertex c1 = graph.addVertex(T.label, "C");
a1.addEdge("ab", b1);
a1.addEdge("ac", c1);
AtomicInteger count = new AtomicInteger(0);
graph.traversal().V(a1).union(__.outE(), __.inE()).forEachRemaining(edge ->
{
a1.addEdge("ab", b1);
c1.addEdge("ac", a1);
count.getAndIncrement();
});
Assert.assertEquals(2, count.get());
}
{code}
In this case TinkerGraph returns 4 and Sqlg 6
TinkerGraph returns 4 as it first walks the 2 out edges and adds 2 in edges
which it sees when traversing the in().
Sqlg return 6 as it lazier than TinkerGraph.
It first walks the "ac" out edge and adds in the 2 edges.
Then walks "ab" and gets 2 edges. The original and the one added previously.
It then walks "ac" in and gets 3 edges as 3 has been added so far.
All and all 6.
I am not sure whats the expected semantics. Sqlg is lazier than TinkerGraph but
not completely lazy either as it depends more on the meta data and number of
queries it needs to execute to walk a particular gremlin query.
I am somewhat of the opinion that without enforcing a eager iteration when
modifying a graph the semantics will be different for different implementors.
For Sqlg at least it will be hard for clients to predict the behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1564) Distributed OLTP Traversals and the Introduction of Partition Concept
[
https://issues.apache.org/jira/browse/TINKERPOP-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15696414#comment-15696414
]
pieter martin commented on TINKERPOP-1564:
--
Ok,
I have never used TinkerPop's as OLAP, are there any OLAP implementation at
present that supports transactions?
If we talk about a transaction do we mean ACID or some weaker, eg. eventually
consistent, form of it?
The only truly distributed ACID system I know of is
[cockroachdb|https://github.com/cockroachdb/cockroach]. Its very interesting
and complex (raft consensus and all that). However its not where TinkerPop is
at, being a layer above the actual transaction/db semantics.
If GremlinServer is going to become a transaction manager managing the
transaction boundary across many remote data sources then it is very close to
the JTA 2 phase XA specification. I remember reading long ago that Neo4j
supports it. Neo4j's transaction implementation is a "proper" JTA specification
implementation if I recall correctly.
Next confusion is, for OLTP across threads, not machines, a similar transaction
manager will have to be present in or near gremlin-core?
> Distributed OLTP Traversals and the Introduction of Partition Concept
> -
>
> Key: TINKERPOP-1564
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1564
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, process, server
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> This proposal unifies OLTP and OLAP into a single framework that removes the
> need for OLAP {{GraphComputer}} by introducing distributed, data local
> processing to OLTP. In essence, this is a proposal for a step-by-step query
> routing framework within {{Traversal}}. This proposal can work across
> machines in a cluster, threads on a machine, or in a hierarchical fashion
> machines The example presented will discuss distribution across
> machines in a cluster as its the most complicated scenario.
> Currently, an OLTP traversal executes at a particular machine (or thread) and
> pulls vertex/edge/etc. data to it accordingly in order to solve the
> traversal. In OLAP, the traversal is cloned and distributed to all machines
> in the cluster and traversals communicate with one another by sending
> {{Traversers}} (i.e. messages) between themselves ensuring data local
> processing. Given recent advancements in GremlinServer and
> {{RemoteTraversal}}, it is possible to add traverser routing to OLTP and
> thus, effect the computational paradigm of Gremlin OLAP in Gremlin OLTP with
> some added benefits not possible in Gremlin OLAP.
> Assume a 4 machine cluster and the following traversal:
> {code}
> g.V(1).out(‘knows’).has(‘age’,gt(20)).out(‘likes’).values(‘name’)
> {code}
> Every time there is a "walk" (adjacency), it is possible that the
> {{Traverser}} is no longer accessing data local to the current machine. In
> order to do data local query routing, every adjacency would feed into a
> {{PartitionStep}}. The traversal above would be cloned (via {{Bytecode}}
> distribution) across the cluster where "sibling" {{PartitionSteps}} would
> have network access to one another using the same protocol of
> {{RemoteConnection}} though called {{PartitionConnection}}. Thus, given the 4
> node cluster example, the above traversal would be overlaid as below. Note
> that {{partition()}} would not be a new step in the language, but simply
> provided here to show where {{PartitionStrategy}} would insert
> {{PartitionSteps}} into the traversal.
> {code}
> g.V(1).out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>^
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
> {code}
> The top traversal is called the "master traversal" and the other three
> "worker traversals." Note that this is identical to current Gremlin OLAP.
> Now, the master traversal would be the traversal that is {{.next()}}'d for
> results. So, when the "master traversal" is {{next()}}'d, {{g.V(1)}} will
> fetch {{v[1]}} and then its outgoing knows-adjacencies. These adjacent
> "reference vertices" would be fed into the first {{remote()}} and a "routing
> algorithm" would determine where
[jira] [Commented] (TINKERPOP-1564) Distributed OLTP Traversals and the Introduction of Partition Concept
[
https://issues.apache.org/jira/browse/TINKERPOP-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15690416#comment-15690416
]
pieter martin commented on TINKERPOP-1564:
--
Will this only work for OLTP if the traversals are executed via GremlinServer?
> Distributed OLTP Traversals and the Introduction of Partition Concept
> -
>
> Key: TINKERPOP-1564
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1564
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, process, server
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> This proposal unifies OLTP and OLAP into a single framework that removes the
> need for OLAP {{GraphComputer}} by introducing distributed, data local
> processing to OLTP. In essence, this is a proposal for a step-by-step query
> routing framework within {{Traversal}}. This proposal can work across
> machines in a cluster, threads on a machine, or in a hierarchical fashion
> machines The example presented will discuss distribution across
> machines in a cluster as its the most complicated scenario.
> Currently, an OLTP traversal executes at a particular machine (or thread) and
> pulls vertex/edge/etc. data to it accordingly in order to solve the
> traversal. In OLAP, the traversal is cloned and distributed to all machines
> in the cluster and traversals communicate with one another by sending
> {{Traversers}} (i.e. messages) between themselves ensuring data local
> processing. Given recent advancements in GremlinServer and
> {{RemoteTraversal}}, it is possible to add traverser routing to OLTP and
> thus, effect the computational paradigm of Gremlin OLAP in Gremlin OLTP with
> some added benefits not possible in Gremlin OLAP.
> Assume a 4 machine cluster and the following traversal:
> {code}
> g.V(1).out(‘knows’).has(‘age’,gt(20)).out(‘likes’).values(‘name’)
> {code}
> Every time there is a "walk" (adjacency), it is possible that the
> {{Traverser}} is no longer accessing data local to the current machine. In
> order to do data local query routing, every adjacency would feed into a
> {{PartitionStep}}. The traversal above would be cloned (via {{Bytecode}}
> distribution) across the cluster where "sibling" {{PartitionSteps}} would
> have network access to one another using the same protocol of
> {{RemoteConnection}} though called {{PartitionConnection}}. Thus, given the 4
> node cluster example, the above traversal would be overlaid as below. Note
> that {{partition()}} would not be a new step in the language, but simply
> provided here to show where {{PartitionStrategy}} would insert
> {{PartitionSteps}} into the traversal.
> {code}
> g.V(1).out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>^
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
> {code}
> The top traversal is called the "master traversal" and the other three
> "worker traversals." Note that this is identical to current Gremlin OLAP.
> Now, the master traversal would be the traversal that is {{.next()}}'d for
> results. So, when the "master traversal" is {{next()}}'d, {{g.V(1)}} will
> fetch {{v[1]}} and then its outgoing knows-adjacencies. These adjacent
> "reference vertices" would be fed into the first {{remote()}} and a "routing
> algorithm" would determine where in the cluster the particular vertex's data
> is. Thus, {{partition()}} ({{PartitionStep}}) serves as a router, pushing
> {{Traversers}} local to the data. Finally, note that the final
> {{PartitionSteps}} can only feed back to the "master traversal" for ultimate
> aggregation and return to the user.
> TinkerPop currently has all the structures in place to make this possible:
> 1. Encapsulation of computational metadata via {{Traverser}}.
> 2. The ability to detach {{Traversers}} and migrate/serialize them via
> {{Traverser.detach()}} and {{Traverser.attach()}}.
> 3. The concept of {{ReferenceElement}} so the traverser only carries
> with it enough information to re-attach at the remote site.
> 4. {{Bytecode}} and the ability to send {{Traversals}} across the
> cluster.
> 5. GremlinServer and {{Client}}/{{Cluster}} messaging protocol.
> What does
[jira] [Closed] (TINKERPOP-1404) Path/label optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin closed TINKERPOP-1404.
Resolution: Fixed
Fix Version/s: 3.3.0
Implemented via TINKERPOP-1372
> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Labels: performance
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r,
> step)}} is called there is no need to call {{Traverser.addLabels}} again in
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}}
> the step's labels can be used directly in the traverser. There is no need to
> make a copy of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1404) Path/label optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15626286#comment-15626286
]
pieter martin commented on TINKERPOP-1404:
--
[~okram] has done the primary optimization of this branch with
[https://issues.apache.org/jira/browse/TINKERPOP-1372]
Closing this for now. I'll do some profiling again to see if the changes
regarding AbstractStep.prepareTraversalForNextStep still have a significant
performance impact.
> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Labels: performance
>
> Currently path queries do a lot of label collection copying. This has a
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r,
> step)}} is called there is no need to call {{Traverser.addLabels}} again in
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}}
> the step's labels can be used directly in the traverser. There is no need to
> make a copy of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1404) Path/label optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15528447#comment-15528447
]
pieter martin commented on TINKERPOP-1404:
--
As the issue scratches rather deep in the steps the idea was for [~twilmes] and
perhaps you to first have a look on the branch before submitting a PR.
[~twilmes] said, on hipchat that he'll have a look.
If you want I can submit a PR instead.
> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Labels: performance
>
> Currently path queries do a lot of label collection copying. This has a
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r,
> step)}} is called there is no need to call {{Traverser.addLabels}} again in
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}}
> the step's labels can be used directly in the traverser. There is no need to
> make a copy of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1404) Path/label optimization
pieter martin created TINKERPOP-1404:
Summary: Path/label optimization
Key: TINKERPOP-1404
URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.2.2
Reporter: pieter martin
Assignee: pieter martin
Currently path queries do a lot of label collection copying. This has a
significant impact on performance.
As the labels are known and set on the traverser when {{Traverser.split(r,
step)}} is called there is no need to call {{Traverser.addLabels}} again in
{{AbstractStep}}
Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}} the
step's labels can be used directly in the traverser. There is no need to make a
copy of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1378) Provide a config for Optout
pieter martin created TINKERPOP-1378:
Summary: Provide a config for Optout
Key: TINKERPOP-1378
URL: https://issues.apache.org/jira/browse/TINKERPOP-1378
Project: TinkerPop
Issue Type: Improvement
Components: test-suite
Affects Versions: 3.2.2
Reporter: pieter martin
Priority: Minor
Currently the {{OptOut}} annotations are specified directly in the main Graph
implementation.
This ticket is to think of a way to specify the {{OptOut}}s in a configuration
file with test scope.
A further concern is to add an additional parameter to the configuration to
name the test suite that the {{OptOut}} applies to.
The reasoning behind this is that an implementation might itself have different
underlying databases with different behavior. So by example,
{{SqlgHsqldbProcessStandardTest}} might {{OptOut}} of different tests to
{{SqlgGraphPostgresProcessStandardTest}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.
[
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353723#comment-15353723
]
pieter martin commented on TINKERPOP-1349:
--
Ok thanks
> RepeatUnrollStrategy should unroll loops while maintaining equivalent
> semantics.
>
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.0-incubating
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.
[
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353670#comment-15353670
]
pieter martin edited comment on TINKERPOP-1349 at 6/28/16 8:41 PM:
---
Ok, tx,
I reran the test but this time iterating the result, so no `count()` and then
the result are equivalent which sets my intuition at rest again.
Nothing to bulk I suppose?
was (Author: pietermartin):
Ok, tx,
I reran the test but this time iterating the result, so now `count()` and then
the result are equivalent which sets my intuition at rest again.
Nothing to bulk I suppose?
> RepeatUnrollStrategy should unroll loops while maintaining equivalent
> semantics.
>
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.0-incubating
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.
[
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353670#comment-15353670
]
pieter martin commented on TINKERPOP-1349:
--
Ok, tx,
I reran the test but this time iterating the result, so now `count()` and then
the result are equivalent which sets my intuition at rest again.
Nothing to bulk I suppose?
> RepeatUnrollStrategy should unroll loops while maintaining equivalent
> semantics.
>
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.0-incubating
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.
[
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353408#comment-15353408
]
pieter martin commented on TINKERPOP-1349:
--
I did not know that the `RepeatStep` is a barrier step. The documentation does
not mention it.
Sqlg also unrolls repeat steps but never inserted barrier steps.
Are you be able to write a sudo test that fails if the barrier steps are not
inserted and I'll test it?
> RepeatUnrollStrategy should unroll loops while maintaining equivalent
> semantics.
>
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.0-incubating
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1349) RepeatUnrollStrategy should unroll loops while maintaining equivalent semantics.
[
https://issues.apache.org/jira/browse/TINKERPOP-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353317#comment-15353317
]
pieter martin commented on TINKERPOP-1349:
--
Why are the barrier steps there?
I would have thought its just {code}out().out().out(){code}
> RepeatUnrollStrategy should unroll loops while maintaining equivalent
> semantics.
>
>
> Key: TINKERPOP-1349
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1349
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.0-incubating
>
>
> Create {{RepeatUnrollStrategy}} that will unroll patterns such as:
> {code}
> repeat(out()).times(3)
> // ->
> out().barrier().out().barrier().out().barrier()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
