[jira] [Updated] (TINKERPOP-3083) The split() step should provide a way to split an entire string
[
https://issues.apache.org/jira/browse/TINKERPOP-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-3083:
---
Description:
There are many use cases where it is helpful to be able to split an entire
string into an array of characters. In other query languages, passing in a null
string ('') as the parameter achieves this. I believe the Gremlin step should
behave the same way. For example
Current behavior
{code:java}
g.inject('Hello').split('')
['Hello']{code}
Proposed new behavior
{code:java}
g.inject('Hello').split('')
['H','e','l','l','o']{code}
was:
There are many use cases here it is helpful to be able to split an entire
string into an array of characters. In other query languages, passing in a null
string ('') as the parameter achieves this. I believe the Gremlin step should
behave the same way. For example
Current behavior
{code:java}
g.inject('Hello').split('')
['Hello']{code}
Proposed new behavior
{code:java}
g.inject('Hello').split('')
['H','e','l','l','o']{code}
> The split() step should provide a way to split an entire string
> ---
>
> Key: TINKERPOP-3083
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3083
> Project: TinkerPop
> Issue Type: Improvement
> Components: language, process
>Affects Versions: 3.7.2
>Reporter: Kelvin Lawrence
>Priority: Major
>
> There are many use cases where it is helpful to be able to split an entire
> string into an array of characters. In other query languages, passing in a
> null string ('') as the parameter achieves this. I believe the Gremlin step
> should behave the same way. For example
> Current behavior
> {code:java}
> g.inject('Hello').split('')
> ['Hello']{code}
> Proposed new behavior
> {code:java}
> g.inject('Hello').split('')
> ['H','e','l','l','o']{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3083) The split() step should provide a way to split an entire string
Kelvin Lawrence created TINKERPOP-3083:
--
Summary: The split() step should provide a way to split an entire
string
Key: TINKERPOP-3083
URL: https://issues.apache.org/jira/browse/TINKERPOP-3083
Project: TinkerPop
Issue Type: Improvement
Components: language, process
Affects Versions: 3.7.2
Reporter: Kelvin Lawrence
There are many use cases here it is helpful to be able to split an entire
string into an array of characters. In other query languages, passing in a null
string ('') as the parameter achieves this. I believe the Gremlin step should
behave the same way. For example
Current behavior
{code:java}
g.inject('Hello').split('')
['Hello']{code}
Proposed new behavior
{code:java}
g.inject('Hello').split('')
['H','e','l','l','o']{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-3074) The sample() step is largely unusable with large graphs
[
https://issues.apache.org/jira/browse/TINKERPOP-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-3074:
---
Description:
While the `sample` step can be useful with smallish sized amounts of data for
random walks and similar, its current implementation makes it unusable with
large graphs if you are looking to sample, say, one node, from a graph with a
millions or billions of nodes in it.
{code:java}
// This generally works assuming the out() step yields limited numbers of nodes
g.V(1).out().sample(1).out().sample(1) //etc
// This fails for a large graph, usually with an OOM error
g.V().sample(1){code}
The current implementation of sample() is quite naive and assumes it can fetch
everything into memory before computing a result. I have seen many users
wanting to start a walk from a random place, and they always try to do
{color:#0747a6}_g.V().sample(1)_{color} or
_{color:#0747a6}g.E().sample(1){color}_ types of queries.
was:
While the `sample` step can be useful with smallish sized amounts of data for
random walks and similar, its current implementation makes it unusable with
large graphs if you are looking to sample, say, one node, from a graph with a
millions or billions of nodes in it.
{code:java}
// This generally works assuming the out() step yields limited numbers of nodes
g.V(1).out().sample(1).out.sample(1) //etc
// This fails for a large graph, usually with an OOM error
g.V().sample(1){code}
The current implementation of sample() is quite naive and assumes it can fetch
everything into memory before computing a result. I have seen many users
wanting to start a walk from a random place, and they always try to do
{color:#0747a6}_g.V().sample(1)_{color} or
_{color:#0747a6}g.E().sample(1){color}_ types of queries.
> The sample() step is largely unusable with large graphs
> ---
>
> Key: TINKERPOP-3074
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3074
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Kelvin Lawrence
>Priority: Major
>
> While the `sample` step can be useful with smallish sized amounts of data for
> random walks and similar, its current implementation makes it unusable with
> large graphs if you are looking to sample, say, one node, from a graph with a
> millions or billions of nodes in it.
> {code:java}
> // This generally works assuming the out() step yields limited numbers of
> nodes
> g.V(1).out().sample(1).out().sample(1) //etc
> // This fails for a large graph, usually with an OOM error
> g.V().sample(1){code}
> The current implementation of sample() is quite naive and assumes it can
> fetch everything into memory before computing a result. I have seen many
> users wanting to start a walk from a random place, and they always try to do
> {color:#0747a6}_g.V().sample(1)_{color} or
> _{color:#0747a6}g.E().sample(1){color}_ types of queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3074) The sample() step is largely unusable with large graphs
Kelvin Lawrence created TINKERPOP-3074:
--
Summary: The sample() step is largely unusable with large graphs
Key: TINKERPOP-3074
URL: https://issues.apache.org/jira/browse/TINKERPOP-3074
Project: TinkerPop
Issue Type: Improvement
Components: process
Reporter: Kelvin Lawrence
While the `sample` step can be useful with smallish sized amounts of data for
random walks and similar, its current implementation makes it unusable with
large graphs if you are looking to sample, say, one node, from a graph with a
millions or billions of nodes in it.
{code:java}
// This generally works assuming the out() step yields limited numbers of nodes
g.V(1).out().sample(1).out.sample(1) //etc
// This fails for a large graph, usually with an OOM error
g.V().sample(1){code}
The current implementation of sample() is quite naive and assumes it can fetch
everything into memory before computing a result. I have seen many users
wanting to start a walk from a random place, and they always try to do
{color:#0747a6}_g.V().sample(1)_{color} or
_{color:#0747a6}g.E().sample(1){color}_ types of queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3073) Unexpected behavior from mergeV onCreate and a property step
Kelvin Lawrence created TINKERPOP-3073:
--
Summary: Unexpected behavior from mergeV onCreate and a property
step
Key: TINKERPOP-3073
URL: https://issues.apache.org/jira/browse/TINKERPOP-3073
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.7.2, 3.6.7, 3.7.1
Reporter: Kelvin Lawrence
One could argue whether this is a bug or a feature request but the following
behavior from the onCreate part of mergeV is confusing for an end user who
expects it to work. You could further argue that specifying cardinality during
onCreate is redundant, but the error message about the default Boolean on the
stream will be very confusing for a user as unless they understand the
implementation will have no idea where that Boolean even comes from.
Setup to reproduce just an empty TinkerGraph and a fairly recent release
{code:java}
gremlin> Gremlin.version()
==>3.7.1
gremlin> g.mergeV([(T.id): 1, (T.label): 'airport']).
..1> option(onCreate, property(single,"prop", 1).constant([:])).
..2> option(onMatch, property(single,"prop",
2).constant([:])).valueMap()
java.lang.Boolean cannot be cast to
org.apache.tinkerpop.gremlin.structure.Element {code}
If the query is rewritten as follows it works fine
{code:java}
gremlin> g.mergeV([(T.id): 1, (T.label): 'airport']).
..1> option(onCreate, [prop: 1]).
..2> option(onMatch, property(single,"prop",
2).constant([:])).valueMap()
==>[prop:[1]]
gremlin> g.mergeV([(T.id): 1, (T.label): 'airport']).
..1> option(onCreate, [prop: 1]).
..2> option(onMatch, property(single,"prop",
2).constant([:])).valueMap()
==>[prop:[2]] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-3036) mergeV updating incorrect vertices and other issues
[
https://issues.apache.org/jira/browse/TINKERPOP-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-3036:
---
Priority: Critical (was: Major)
> mergeV updating incorrect vertices and other issues
> ---
>
> Key: TINKERPOP-3036
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3036
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Kelvin Lawrence
>Priority: Critical
>
> The following Stack Overflow post (link below) reported some issues with
> mergeV when side effects and cardinality are used (as well as with 3 mergeV
> steps chained together). The issue reproduces on 3.7.1 using TinkerGraph.
> [https://stackoverflow.com/questions/77803485/batch-mergev-working-well-when-creating-items-but-yielding-unexpected-results-w]
>
> Reproduction steps
>
> {code:java}
> gremlin> g=TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.mergeV([(T.id):'v-1']).
> ..1> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 12]).
> ..2> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..3> sideEffect(property(single, 'age',
> 22)).constant([:])).
> ..4> mergeV([(T.id):'v-2']).
> ..5> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 13]).
> ..6> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..7> sideEffect(property(single, 'age',
> 23)).constant([:])).
> ..8> mergeV([(T.id):'v-3']).
> ..9> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 14]).
> .10> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> .11> sideEffect(property(single, 'age',
> 24)).constant([:])).
> .12> id()
> ==>v-3
> gremlin> g.V().valueMap(true)
> ==>[id:v-2,label:Person,email:[perso...@example.org],age:[13]]
> ==>[id:v-1,label:Person,email:[perso...@example.org],age:[12]]
> ==>[id:v-3,label:Person,email:[perso...@example.org],age:[14]]
> gremlin> g.mergeV([(T.id):'v-1']).
> ..1> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 12]).
> ..2> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..3> sideEffect(property(single, 'age',
> 22)).constant([:])).
> ..4> mergeV([(T.id):'v-2']).
> ..5> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 13]).
> ..6> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> ..7> sideEffect(property(single, 'age',
> 23)).constant([:])).
> ..8> mergeV([(T.id):'v-3']).
> ..9> option(onCreate, [(T.label): 'Person', 'email':
> 'perso...@example.org', 'age': 14]).
> .10> option(onMatch, sideEffect(property(single, 'email',
> 'perso...@example.org')).
> .11> sideEffect(property(single, 'age',
> 24)).constant([:])).
> .12> id()
> ==>v-3
> gremlin> g.V().valueMap(true)
> ==>[id:v-2,label:Person,email:[perso...@example.org],age:[24]]
> ==>[id:v-1,label:Person,email:[perso...@example.org],age:[23]]
> ==>[id:v-3,label:Person,email:[perso...@example.org],age:[14]]
> gremlin> {code}
> The query seems to be both updating values in the incorrect vertices as well
> as leaving some values unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3036) mergeV updating incorrect vertices and other issues
Kelvin Lawrence created TINKERPOP-3036:
--
Summary: mergeV updating incorrect vertices and other issues
Key: TINKERPOP-3036
URL: https://issues.apache.org/jira/browse/TINKERPOP-3036
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.7.1
Reporter: Kelvin Lawrence
The following Stack Overflow post (link below) reported some issues with mergeV
when side effects and cardinality are used (as well as with 3 mergeV steps
chained together). The issue reproduces on 3.7.1 using TinkerGraph.
[https://stackoverflow.com/questions/77803485/batch-mergev-working-well-when-creating-items-but-yielding-unexpected-results-w]
Reproduction steps
{code:java}
gremlin> g=TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.mergeV([(T.id):'v-1']).
..1> option(onCreate, [(T.label): 'Person', 'email':
'perso...@example.org', 'age': 12]).
..2> option(onMatch, sideEffect(property(single, 'email',
'perso...@example.org')).
..3> sideEffect(property(single, 'age',
22)).constant([:])).
..4> mergeV([(T.id):'v-2']).
..5> option(onCreate, [(T.label): 'Person', 'email':
'perso...@example.org', 'age': 13]).
..6> option(onMatch, sideEffect(property(single, 'email',
'perso...@example.org')).
..7> sideEffect(property(single, 'age',
23)).constant([:])).
..8> mergeV([(T.id):'v-3']).
..9> option(onCreate, [(T.label): 'Person', 'email':
'perso...@example.org', 'age': 14]).
.10> option(onMatch, sideEffect(property(single, 'email',
'perso...@example.org')).
.11> sideEffect(property(single, 'age',
24)).constant([:])).
.12> id()
==>v-3
gremlin> g.V().valueMap(true)
==>[id:v-2,label:Person,email:[perso...@example.org],age:[13]]
==>[id:v-1,label:Person,email:[perso...@example.org],age:[12]]
==>[id:v-3,label:Person,email:[perso...@example.org],age:[14]]
gremlin> g.mergeV([(T.id):'v-1']).
..1> option(onCreate, [(T.label): 'Person', 'email':
'perso...@example.org', 'age': 12]).
..2> option(onMatch, sideEffect(property(single, 'email',
'perso...@example.org')).
..3> sideEffect(property(single, 'age',
22)).constant([:])).
..4> mergeV([(T.id):'v-2']).
..5> option(onCreate, [(T.label): 'Person', 'email':
'perso...@example.org', 'age': 13]).
..6> option(onMatch, sideEffect(property(single, 'email',
'perso...@example.org')).
..7> sideEffect(property(single, 'age',
23)).constant([:])).
..8> mergeV([(T.id):'v-3']).
..9> option(onCreate, [(T.label): 'Person', 'email':
'perso...@example.org', 'age': 14]).
.10> option(onMatch, sideEffect(property(single, 'email',
'perso...@example.org')).
.11> sideEffect(property(single, 'age',
24)).constant([:])).
.12> id()
==>v-3
gremlin> g.V().valueMap(true)
==>[id:v-2,label:Person,email:[perso...@example.org],age:[24]]
==>[id:v-1,label:Person,email:[perso...@example.org],age:[23]]
==>[id:v-3,label:Person,email:[perso...@example.org],age:[14]]
gremlin> {code}
The query seems to be both updating values in the incorrect vertices as well as
leaving some values unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2957) mergeV with sideEffect not correctly updating properties
[
https://issues.apache.org/jira/browse/TINKERPOP-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2957:
---
Description:
A Gremlin user let me know about the following issue. If the query below is run
twice, the name parameter on the 4567 vertex does not get updated. The name on
the 1234 vertex does get updated. The query is written this way as not all
databases support single cardinality as the default. The issue has been
reproduced using both TinkerGraph and Amazon Neptune.
{code:java}
g.mergeV([(T.id): 'test-test-1234']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
mergeV([(T.id): 'test-test-4567']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch,
sideEffect(property(single,"name","name2")).constant([:])){code}
was:
A Gremlin user let me know about the following issue. If the query below is run
twice, the name parameter on the 4567 vertex does not get updated. The name on
the 1234 vertex does get updated. The query is written this way as not all
databases support single cardinality as the default. The issue has been
reproduced using both TinkerGraph and Amazon Neptune.
g.mergeV([(T.id): 'test-test-1234']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
mergeV([(T.id): 'test-test-4567']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch, sideEffect(property(single,"name","name2")).constant([:]))
> mergeV with sideEffect not correctly updating properties
>
>
> Key: TINKERPOP-2957
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2957
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.4
>Reporter: Kelvin Lawrence
>Priority: Major
>
> A Gremlin user let me know about the following issue. If the query below is
> run twice, the name parameter on the 4567 vertex does not get updated. The
> name on the 1234 vertex does get updated. The query is written this way as
> not all databases support single cardinality as the default. The issue has
> been reproduced using both TinkerGraph and Amazon Neptune.
> {code:java}
> g.mergeV([(T.id): 'test-test-1234']).
> option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
> option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
> mergeV([(T.id): 'test-test-4567']).
> option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
> option(onMatch,
> sideEffect(property(single,"name","name2")).constant([:])){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2957) mergeV with sideEffect not correctly updating properties
Kelvin Lawrence created TINKERPOP-2957: -- Summary: mergeV with sideEffect not correctly updating properties Key: TINKERPOP-2957 URL: https://issues.apache.org/jira/browse/TINKERPOP-2957 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.6.4 Reporter: Kelvin Lawrence A Gremlin user let me know about the following issue. If the query below is run twice, the name parameter on the 4567 vertex does not get updated. The name on the 1234 vertex does get updated. The query is written this way as not all databases support single cardinality as the default. The issue has been reproduced using both TinkerGraph and Amazon Neptune. g.mergeV([(T.id): 'test-test-1234']). option(onCreate, [(T.label): 'someLabel', 'name': 'name1']). option(onMatch, sideEffect(property(single,"name","name2")).constant([:])). mergeV([(T.id): 'test-test-4567']). option(onCreate, [(T.label): 'someLabel', 'name': 'name1']). option(onMatch, sideEffect(property(single,"name","name2")).constant([:])) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2906) Query using coalesce adding the same vertex twice
[
https://issues.apache.org/jira/browse/TINKERPOP-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708053#comment-17708053
]
Kelvin Lawrence commented on TINKERPOP-2906:
Thanks Stephen - seems I convinced myself I was seeing something that wasn't
there. Sorry for the red herring on this one :(
> Query using coalesce adding the same vertex twice
> -
>
> Key: TINKERPOP-2906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2906
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.0, 3.6.2
>Reporter: Kelvin Lawrence
>Priority: Critical
>
> While looking into a question on Stack Overflow about selectively adding a
> vertex based on a set of values in a list, I think I may have run into an odd
> issue. Note that this can also be solved using mergeV, but that
> notwithstanding, the behavior below seems odd. It can be reproduced just
> using TinkerGraph and the Gremlin Console. Everything works as expected until
> the RHS of the coalesce() step is an addV() step.
>
> {code:java}
> gremlin> g.addV('Person').property('name','Sam')
> ==>v[16]gremlin> g
> ==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),constant(1))
> ==>v[16]
> ==>1
> ==>1gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),select('find'))
> ==>v[16]
> ==>Peter
> ==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),addV('Person').property('name',select('find'))
> ..7> )
> ==>v[16]
> ==>v[18]
> ==>v[20]
> ==>v[22]gremlin> g.V().valueMap(true)
> ==>[id:16,label:Person,name:[Sam]]
> ==>[id:18,label:Person,name:[Peter]]
> ==>[id:20,label:Person,name:[Frank]]
> ==>[id:22,label:Person,name:[Frank]]
>
> gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
> ==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),
> ..7> addV('Person').property('name',select('find'))).profile()
> ==>Traversal Metrics
> Step Count Traversers Time (ms) % Dur
> =
> InjectStep([[Sam, Peter, Frank]]) 1 1 0.043 4.19
> UnfoldStep@[find] 3 3 0.083 8.00
> TinkerGraphStep(vertex,[])@[p] 4 4 0.155 14.91
> CoalesceStep([[WherePredicateStep(null,eq(p),[[... 4 4 0.761 72.89
> WherePredicateStep(null,eq(p),[[SelectOneStep... 1 1 0.181
> SelectOneStep(last,find,null) 4 4 0.057
> AddVertexStep({name=[[SelectOneStep(last,find... 3 3 0.246
> SelectOneStep(last,find,null) 3 3 0.025
> >TOTAL - - 1.044 -
> gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').V().profile()
> ==>Traversal Metrics
> Step Count Traversers Time (ms) % Dur
> =
> InjectStep([[Sam, Peter, Frank]]) 1 1 0.028 8.93
> UnfoldStep@[find] 3 3 0.043 13.97
> TinkerGraphStep(vertex,[]) 3 3 0.241 77.10
> >TOTAL - - 0.313 -
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2906) Query using coalesce adding the same vertex twice
[
https://issues.apache.org/jira/browse/TINKERPOP-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2906:
---
Description:
While looking into a question on Stack Overflow about selectively adding a
vertex based on a set of values in a list, I think I may have run into an odd
issue. Note that this can also be solved using mergeV, but that
notwithstanding, the behavior below seems odd. It can be reproduced just using
TinkerGraph and the Gremlin Console. Everything works as expected until the RHS
of the coalesce() step is an addV() step.
gremlin> g.addV('Person').property('name','Sam')
==>v[16]gremlin> g
==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),constant(1))
==>v[16]
==>1
==>1gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),select('find'))
==>v[16]
==>Peter
==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),addV('Person').property('name',select('find'))
..7> )
==>v[16]
==>v[18]
==>v[20]
==>v[22]gremlin> g.V().valueMap(true)
==>[id:16,label:Person,name:[Sam]]
==>[id:18,label:Person,name:[Peter]]
==>[id:20,label:Person,name:[Frank]]
==>[id:22,label:Person,name:[Frank]]
gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),
..7> addV('Person').property('name',select('find'))).profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=
InjectStep([[Sam, Peter, Frank]]) 1 1 0.043 4.19
UnfoldStep@[find] 3 3 0.083 8.00
TinkerGraphStep(vertex,[])@[p] 4 4 0.155 14.91
CoalesceStep([[WherePredicateStep(null,eq(p),[[... 4 4 0.761 72.89
WherePredicateStep(null,eq(p),[[SelectOneStep... 1 1 0.181
SelectOneStep(last,find,null) 4 4 0.057
AddVertexStep({name=[[SelectOneStep(last,find... 3 3 0.246
SelectOneStep(last,find,null) 3 3 0.025
>TOTAL - - 1.044 -
gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').V().profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=
InjectStep([[Sam, Peter, Frank]]) 1 1 0.028 8.93
UnfoldStep@[find] 3 3 0.043 13.97
TinkerGraphStep(vertex,[]) 3 3 0.241 77.10
>TOTAL - - 0.313 -
was:
Will looking into a question on Stack Overflow about selectively adding a
vertex based on a set of values in a list, I think I may have run into an odd
issue. Note that this can also be solved using mergeV, but that
notwithstanding, the behavior below seems odd. It can be reproduced just using
TinkerGraph and the Gremlin Console. Everything works as expected until the RHS
of the coalesce() step is an addV() step.
gremlin> g.addV('Person').property('name','Sam')
==>v[16]gremlin> g
==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),constant(1))
==>v[16]
==>1
==>1gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),select('find'))
==>v[16]
==>Peter
==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),addV('Person').property('name',select('find'))
..7> )
==>v[16]
==>v[18]
==>v[20]
==>v[22]gremlin> g.V().valueMap(true)
==>[id:16,label:Person,name:[Sam]]
==>[id:18,label:Person,name:[Peter]]
==>[id:20,label:Person,name:[Frank]]
==>[id:22,label:Person,name:[Frank]]
gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),
..7> addV('Person').property('name',select('find'))).profile()
==>Traversal Metrics
Step
[jira] [Updated] (TINKERPOP-2906) Query using coalesce adding the same vertex twice
[
https://issues.apache.org/jira/browse/TINKERPOP-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2906:
---
Description:
While looking into a question on Stack Overflow about selectively adding a
vertex based on a set of values in a list, I think I may have run into an odd
issue. Note that this can also be solved using mergeV, but that
notwithstanding, the behavior below seems odd. It can be reproduced just using
TinkerGraph and the Gremlin Console. Everything works as expected until the RHS
of the coalesce() step is an addV() step.
{code:java}
gremlin> g.addV('Person').property('name','Sam')
==>v[16]gremlin> g
==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),constant(1))
==>v[16]
==>1
==>1gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),select('find'))
==>v[16]
==>Peter
==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),addV('Person').property('name',select('find'))
..7> )
==>v[16]
==>v[18]
==>v[20]
==>v[22]gremlin> g.V().valueMap(true)
==>[id:16,label:Person,name:[Sam]]
==>[id:18,label:Person,name:[Peter]]
==>[id:20,label:Person,name:[Frank]]
==>[id:22,label:Person,name:[Frank]]
gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),
..7> addV('Person').property('name',select('find'))).profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=
InjectStep([[Sam, Peter, Frank]]) 1 1 0.043 4.19
UnfoldStep@[find] 3 3 0.083 8.00
TinkerGraphStep(vertex,[])@[p] 4 4 0.155 14.91
CoalesceStep([[WherePredicateStep(null,eq(p),[[... 4 4 0.761 72.89
WherePredicateStep(null,eq(p),[[SelectOneStep... 1 1 0.181
SelectOneStep(last,find,null) 4 4 0.057
AddVertexStep({name=[[SelectOneStep(last,find... 3 3 0.246
SelectOneStep(last,find,null) 3 3 0.025
>TOTAL - - 1.044 -
gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').V().profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=
InjectStep([[Sam, Peter, Frank]]) 1 1 0.028 8.93
UnfoldStep@[find] 3 3 0.043 13.97
TinkerGraphStep(vertex,[]) 3 3 0.241 77.10
>TOTAL - - 0.313 -
{code}
was:
While looking into a question on Stack Overflow about selectively adding a
vertex based on a set of values in a list, I think I may have run into an odd
issue. Note that this can also be solved using mergeV, but that
notwithstanding, the behavior below seems odd. It can be reproduced just using
TinkerGraph and the Gremlin Console. Everything works as expected until the RHS
of the coalesce() step is an addV() step.
gremlin> g.addV('Person').property('name','Sam')
==>v[16]gremlin> g
==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),constant(1))
==>v[16]
==>1
==>1gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),select('find'))
==>v[16]
==>Peter
==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),addV('Person').property('name',select('find'))
..7> )
==>v[16]
==>v[18]
==>v[20]
==>v[22]gremlin> g.V().valueMap(true)
==>[id:16,label:Person,name:[Sam]]
==>[id:18,label:Person,name:[Peter]]
==>[id:20,label:Person,name:[Frank]]
==>[id:22,label:Person,name:[Frank]]
gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),
..7> addV('Person').property('name',select('find'))).profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
==
[jira] [Created] (TINKERPOP-2906) Query using coalesce adding the same vertex twice
Kelvin Lawrence created TINKERPOP-2906:
--
Summary: Query using coalesce adding the same vertex twice
Key: TINKERPOP-2906
URL: https://issues.apache.org/jira/browse/TINKERPOP-2906
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.6.2, 3.6.0
Reporter: Kelvin Lawrence
Will looking into a question on Stack Overflow about selectively adding a
vertex based on a set of values in a list, I think I may have run into an odd
issue. Note that this can also be solved using mergeV, but that
notwithstanding, the behavior below seems odd. It can be reproduced just using
TinkerGraph and the Gremlin Console. Everything works as expected until the RHS
of the coalesce() step is an addV() step.
gremlin> g.addV('Person').property('name','Sam')
==>v[16]gremlin> g
==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),constant(1))
==>v[16]
==>1
==>1gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),select('find'))
==>v[16]
==>Peter
==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),addV('Person').property('name',select('find'))
..7> )
==>v[16]
==>v[18]
==>v[20]
==>v[22]gremlin> g.V().valueMap(true)
==>[id:16,label:Person,name:[Sam]]
==>[id:18,label:Person,name:[Peter]]
==>[id:20,label:Person,name:[Frank]]
==>[id:22,label:Person,name:[Frank]]
gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').
..2> V().as('p').
..3> coalesce(
..4> where(eq('p')).
..5> by(select('find')).
..6> by('name'),
..7> addV('Person').property('name',select('find'))).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
InjectStep([[Sam, Peter, Frank]]) 1
1 0.043 4.19
UnfoldStep@[find] 3
3 0.083 8.00
TinkerGraphStep(vertex,[])@[p] 4
4 0.15514.91
CoalesceStep([[WherePredicateStep(null,eq(p),[[... 4
4 0.76172.89
WherePredicateStep(null,eq(p),[[SelectOneStep... 1
1 0.181
SelectOneStep(last,find,null) 4
4 0.057
AddVertexStep({name=[[SelectOneStep(last,find... 3
3 0.246
SelectOneStep(last,find,null) 3
3 0.025
>TOTAL -
- 1.044-
gremlin> g.inject(['Sam','Peter','Frank']).
..1> unfold().as('find').V().profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
InjectStep([[Sam, Peter, Frank]]) 1
1 0.028 8.93
UnfoldStep@[find] 3
3 0.04313.97
TinkerGraphStep(vertex,[]) 3
3 0.24177.10
>TOTAL -
- 0.313-
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2870) mergeV requires key of 'new' to be quoted
[
https://issues.apache.org/jira/browse/TINKERPOP-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2870:
---
Priority: Minor (was: Major)
> mergeV requires key of 'new' to be quoted
> -
>
> Key: TINKERPOP-2870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2870
> Project: TinkerPop
> Issue Type: Bug
> Components: language
>Affects Versions: 3.6.0, 3.6.1, 3.6.2
>Reporter: Kelvin Lawrence
>Priority: Minor
>
> When using text based queries the Antlr grammar does not seem to like certain
> keys being unquoted. In the example below, there will be a parse error thrown
> unless the key 'new' is in quotes. Note the other keys used are not quoted.
>
> {code:java}
> g.mergeV([id:'X1', name:'M1']).
> option(Merge.onCreate,['new':true]).
> option(Merge.onMatch,[year:2023]).
> valueMap()
> {'new': [True], 'year': [2023], 'name': ['M1']}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2870) mergeV requires key of 'new' to be quoted
[
https://issues.apache.org/jira/browse/TINKERPOP-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2870:
---
Description:
When using text based queries the Antlr grammar does not seem to like certain
keys being unquoted. In the example below, there will be a parse error thrown
unless the key 'new' is in quotes. Note the other keys used are not quoted.
{code:java}
g.mergeV([id:'X1', name:'M1']).
option(Merge.onCreate,['new':true]).
option(Merge.onMatch,[year:2023]).
valueMap()
{'new': [True], 'year': [2023], 'name': ['M1']}
{code}
was:
When using text based queries the Antlr grammar does not seem to like certain
keys being unquoted. In the example below, there will be a parse error thrown
unless the key 'new' is in quotes. Note the other keys used are not quoted.
g.mergeV([id:'X1', name:'M1']).
option(Merge.onCreate,['new':true]).
option(Merge.onMatch,[year:2023]).
valueMap()
\{'new': [True], 'year': [2023], 'name': ['M1']}
> mergeV requires key of 'new' to be quoted
> -
>
> Key: TINKERPOP-2870
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2870
> Project: TinkerPop
> Issue Type: Bug
> Components: language
>Affects Versions: 3.6.0, 3.6.1, 3.6.2
>Reporter: Kelvin Lawrence
>Priority: Major
>
> When using text based queries the Antlr grammar does not seem to like certain
> keys being unquoted. In the example below, there will be a parse error thrown
> unless the key 'new' is in quotes. Note the other keys used are not quoted.
>
> {code:java}
> g.mergeV([id:'X1', name:'M1']).
> option(Merge.onCreate,['new':true]).
> option(Merge.onMatch,[year:2023]).
> valueMap()
> {'new': [True], 'year': [2023], 'name': ['M1']}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2870) mergeV requires key of 'new' to be quoted
Kelvin Lawrence created TINKERPOP-2870:
--
Summary: mergeV requires key of 'new' to be quoted
Key: TINKERPOP-2870
URL: https://issues.apache.org/jira/browse/TINKERPOP-2870
Project: TinkerPop
Issue Type: Bug
Components: language
Affects Versions: 3.6.2, 3.6.1, 3.6.0
Reporter: Kelvin Lawrence
When using text based queries the Antlr grammar does not seem to like certain
keys being unquoted. In the example below, there will be a parse error thrown
unless the key 'new' is in quotes. Note the other keys used are not quoted.
g.mergeV([id:'X1', name:'M1']).
option(Merge.onCreate,['new':true]).
option(Merge.onMatch,[year:2023]).
valueMap()
\{'new': [True], 'year': [2023], 'name': ['M1']}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2856) math() step fails if variable name contains a keyword
[
https://issues.apache.org/jira/browse/TINKERPOP-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2856:
---
Description:
As reported on
[StackOverflow|https://stackoverflow.com/questions/74121856/gremlin-reserved-word-exp]
if a variable used as part of the math() step contains a reserved word such as
"exp" the evaluation of the expression fails. For example
{code:java}
math('number1-expected_value').next(){code}
results in
{code:java}
*GremlinServerError: 499: {"detailedMessage":"Unknown function or variable
'cted_value' at pos 20 in expression 'number1 -
expected_value'","requestId":"01e3f9e6-3cf2-4af0-bf94-5a4979d488b4","code":"InvalidParameterException"}*{code}
{{{}I am able to reproduce this in the Gremlin Console using TinkerPop version
3.6.0 using:{}}}}}{}}}
{code:java}
gremlin> g.inject(1).as('expa').constant(2).as('c').math('c - expa')
Unknown function or variable 'a' at pos 7 in expression 'c - expa'
Type ':help' or ':h' for help.
Display stack trace? [yN]
gremlin> g.inject(1).as('a').constant(2).as('c').math('c - a')
==>1.0 {code}
was:
As reported on
[StackOverflow|https://stackoverflow.com/questions/74121856/gremlin-reserved-word-exp]
if a variable used as part of the math() step contains a reserved word such as
"exp" the evaluation of the expression fails. For example
{{}}
{code:java}
math('number1-expected_value').next(){code}
{{}}
results in
{{}}
{{}}
{code:java}
{code}
{{**GremlinServerError: 499: \{"detailedMessage":"Unknown function or variable
'cted_value' at pos 20 in expression 'number1 -
expected_value'","requestId":"01e3f9e6-3cf2-4af0-bf94-5a4979d488b4","code":"InvalidParameterException"}**}}
{{{}I am able to reproduce this in the Gremlin Console using TinkerPop version
3.6.0 using:{}}}{{{}{}}}
{code:java}
gremlin> g.inject(1).as('expa').constant(2).as('c').math('c - expa')
Unknown function or variable 'a' at pos 7 in expression 'c - expa'
Type ':help' or ':h' for help.
Display stack trace? [yN]
gremlin> g.inject(1).as('a').constant(2).as('c').math('c - a')
==>1.0 {code}
{{}}
{{}}
{{}}
> math() step fails if variable name contains a keyword
> -
>
> Key: TINKERPOP-2856
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2856
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Environment: Any Gremlin version that has the math() step. Reproduced
> on 3.6.0
>Reporter: Kelvin Lawrence
>Priority: Major
>
> As reported on
> [StackOverflow|https://stackoverflow.com/questions/74121856/gremlin-reserved-word-exp]
> if a variable used as part of the math() step contains a reserved word such
> as "exp" the evaluation of the expression fails. For example
>
> {code:java}
> math('number1-expected_value').next(){code}
> results in
> {code:java}
> *GremlinServerError: 499: {"detailedMessage":"Unknown function or variable
> 'cted_value' at pos 20 in expression 'number1 -
> expected_value'","requestId":"01e3f9e6-3cf2-4af0-bf94-5a4979d488b4","code":"InvalidParameterException"}*{code}
> {{{}I am able to reproduce this in the Gremlin Console using TinkerPop
> version 3.6.0 using:{}}}}}{}}}
> {code:java}
> gremlin> g.inject(1).as('expa').constant(2).as('c').math('c - expa')
> Unknown function or variable 'a' at pos 7 in expression 'c - expa'
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> gremlin> g.inject(1).as('a').constant(2).as('c').math('c - a')
> ==>1.0 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2856) math() step fails if variable name contains a keyword
Kelvin Lawrence created TINKERPOP-2856:
--
Summary: math() step fails if variable name contains a keyword
Key: TINKERPOP-2856
URL: https://issues.apache.org/jira/browse/TINKERPOP-2856
Project: TinkerPop
Issue Type: Bug
Components: process
Environment: Any Gremlin version that has the math() step. Reproduced
on 3.6.0
Reporter: Kelvin Lawrence
As reported on
[StackOverflow|https://stackoverflow.com/questions/74121856/gremlin-reserved-word-exp]
if a variable used as part of the math() step contains a reserved word such as
"exp" the evaluation of the expression fails. For example
{{}}
{code:java}
math('number1-expected_value').next(){code}
{{}}
results in
{{}}
{{}}
{code:java}
{code}
{{**GremlinServerError: 499: \{"detailedMessage":"Unknown function or variable
'cted_value' at pos 20 in expression 'number1 -
expected_value'","requestId":"01e3f9e6-3cf2-4af0-bf94-5a4979d488b4","code":"InvalidParameterException"}**}}
{{{}I am able to reproduce this in the Gremlin Console using TinkerPop version
3.6.0 using:{}}}{{{}{}}}
{code:java}
gremlin> g.inject(1).as('expa').constant(2).as('c').math('c - expa')
Unknown function or variable 'a' at pos 7 in expression 'c - expa'
Type ':help' or ':h' for help.
Display stack trace? [yN]
gremlin> g.inject(1).as('a').constant(2).as('c').math('c - a')
==>1.0 {code}
{{}}
{{}}
{{}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2851) TinkerPop could not deal with correct path traversal results
[
https://issues.apache.org/jira/browse/TINKERPOP-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17655005#comment-17655005
]
Kelvin Lawrence commented on TINKERPOP-2851:
Thanks for the Jira [~zeyangzhuang] . I'm having trouble understanding how to
reproduce the issue in the absence of some sample data. Are you able to attach
the *{{addV}}* and *{{addE}}* steps to this issue that create a sample graph
that helps in reproducing the behavior you are seeing?
> TinkerPop could not deal with correct path traversal results
>
>
> Key: TINKERPOP-2851
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2851
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.10, 3.6.1
> Environment: Version: 3.4.10
> Storage Backend: in-memory
>Reporter: Zeyang Zhuang
>Priority: Major
>
> - Expected Behavior:
> We construct the following scenario: x equals count nodes(A->B) path numbers,
> y equals count nodes(B->C) path numbers, z equals count(A->B->C) path
> numbers. Then z should equal to x*y.
> We generate graph schema and data based on random strings and values. We
> build the graph with 100 vertexes, 200 edges, 20 vertex labels, and 20 edge
> labels.
> `g.V().id()` is used to get the node ids of the graph, then can use for loop
> to traverse all the nodes. Here is one of our examples executed.
> 1) `g.V(46).repeat(out().simplePath()).until(hasId(0)).path().size()` return 9
> 2) `g.V(0).repeat(out().simplePath()).until(hasId(276)).path().size()` return
> 8
> 3)
> `g.V(46).repeat(out().simplePath()).until(hasId(0)).repeat(out().simplePath()).until(hasId(276)).path().size()`,
> should return 9*8.
> - Current Behavior:
> The query 3 return 7 != 9*8.
> - Steps to Reproduce:
> Although the randomness of the graph data generation process, we still find
> the problem after many attempts. Reproduce: Generate a large enough graph ->
> Get all node ids -> Count the number of paths for any two ids -> Multiply and
> compare following our strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2823) A drop() after a union() does not drop everything found
[
https://issues.apache.org/jira/browse/TINKERPOP-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2823:
---
Description:
This may be related to https://issues.apache.org/jira/browse/TINKERPOP-2627,
but on the surface appears different.
If a `drop()` step appears after a `union()` step, Gremlin does not drop all of
the vertices that flow out of the `union()`. It only drops one vertex.
For example, using the air routes data, we can see that V(44) has four outgoing
routes, and the `union()` correctly yields five results. However, if a `drop()`
is performed after the `union()` only V(44) gets dropped. As a workaround,
doing `union().fold().unfold().drop()` does work and all five vertices get
deleted.
{code:java}
gremlin> g.V().count()
==>3748
gremlin> g.V(44).union(identity(),out()).count()
==>5
gremlin> g.V(44).union(identity(),out()).drop()
// Only one has been dropped
gremlin> g.V().count()
==>3747 {code}
We can see by profiling the two queries that the number of traversers stays at
one, if a drop() step is present, whereas it is five otherwise.
{code:java}
gremlin> g.V(44).union(identity(),out()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms) % Dur
=
TinkerGraphStep(vertex,[44]) 1
1 0.255 26.98
UnionStep([[IdentityStep, EndStep], [VertexStep... 5
5 0.691 73.02
IdentityStep 1
1 0.017
EndStep 1
1 0.014
VertexStep(OUT,vertex) 4
4 0.069
EndStep 4
4 0.072
>TOTAL -
- 0.947 -
gremlin> g.V(44).union(identity(),out()).drop().profile()
==>Traversal Metrics
Step Count
Traversers Time (ms) % Dur
=
TinkerGraphStep(vertex,[44]) 1
1 0.073 19.44
UnionStep([[IdentityStep, EndStep], [VertexStep... 1
1 0.159 42.40
IdentityStep 1
1 0.006
EndStep 1
1 0.009
VertexStep(OUT,vertex)
0.025
EndStep
0.016
DropStep
0.143 38.16
>TOTAL -
- 0.376 -
gremlin> {code}
This issue was also reported via a StackOverflow post:
[https://stackoverflow.com/questions/74238687/why-does-my-gremlin-query-not-drop-all-the-vertices-i-indicate]
was:
This may be related to https://issues.apache.org/jira/browse/TINKERPOP-2627,
but on the surface appears different.
If a `drop()` step appears after a `union()` step, Gremlin does not drop all of
the vertices that flow out of the `union()`. It only drops one vertex.
For example, using the air routes data, we can see that V(44) has four outgoing
routes, and the `union()` correctly yields five results. However, if a `drop()`
is performed after the `union()` only V(44) gets dropped. As a workaround,
doing `union().fold().unfold().drop()` does work and all five vertices get
deleted.
{code:java}
gremlin> g.V().count()
==>3748
gremlin> g.V(44).union(identity(),out()).count()
==>5
gremlin> g.V(44).union(identity(),out()).drop()
// Only one has been dropped
gremlin> g.V().count()
==>3747 {code}
We can see by profiling the two queries that the number of traversers stays at
one, if a drop() step is present, whereas it is five otherwise.
{code:java}
gremlin> g.V(44).union(identity(),out()).profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=
TinkerGraphStep(vertex,[44]) 1 1 0.143 48.36
UnionStep([[IdentityStep, EndStep], [VertexStep... 5 5 0.153 51.64
IdentityStep 1 1 0.009
EndStep 1 1 0.008
VertexStep(OUT,vertex) 4 4 0.017
EndStep 4 4 0.013
>TOTAL - - 0.296 -gremlin
[jira] [Updated] (TINKERPOP-2823) A drop() after a union() does not drop everything found
[
https://issues.apache.org/jira/browse/TINKERPOP-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Lawrence updated TINKERPOP-2823:
---
Description:
This may be related to https://issues.apache.org/jira/browse/TINKERPOP-2627,
but on the surface appears different.
If a `drop()` step appears after a `union()` step, Gremlin does not drop all of
the vertices that flow out of the `union()`. It only drops one vertex.
For example, using the air routes data, we can see that V(44) has four outgoing
routes, and the `union()` correctly yields five results. However, if a `drop()`
is performed after the `union()` only V(44) gets dropped. As a workaround,
doing `union().fold().unfold().drop()` does work and all five vertices get
deleted.
{code:java}
gremlin> g.V().count()
==>3748
gremlin> g.V(44).union(identity(),out()).count()
==>5
gremlin> g.V(44).union(identity(),out()).drop()
// Only one has been dropped
gremlin> g.V().count()
==>3747 {code}
We can see by profiling the two queries that the number of traversers stays at
one, if a drop() step is present, whereas it is five otherwise.
{code:java}
gremlin> g.V(44).union(identity(),out()).profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=
TinkerGraphStep(vertex,[44]) 1 1 0.143 48.36
UnionStep([[IdentityStep, EndStep], [VertexStep... 5 5 0.153 51.64
IdentityStep 1 1 0.009
EndStep 1 1 0.008
VertexStep(OUT,vertex) 4 4 0.017
EndStep 4 4 0.013
>TOTAL - - 0.296 -gremlin> g.V(44).union(identity(),out()).drop().profile()
==>Traversal Metrics
Step Count Traversers Time (ms) % Dur
=
TinkerGraphStep(vertex,[44]) 1 1 0.097 1.64
UnionStep([[IdentityStep, EndStep], [VertexStep... 1 1 0.194 3.25
IdentityStep 1 1 0.020
EndStep 1 1 0.008
VertexStep(OUT,vertex) 0.051
EndStep 0.018
DropStep 5.695 95.11
>TOTAL - - 5.987 -{code}
This issue was also reported via a StackOverflow post:
[https://stackoverflow.com/questions/74238687/why-does-my-gremlin-query-not-drop-all-the-vertices-i-indicate]
was:
This may be related to https://issues.apache.org/jira/browse/TINKERPOP-2627,
but on the surface appears different.
If a `drop()` step appears after a `union()` step, Gremlin does not drop all of
the vertices that flow out of the `union()`. It only drops one vertex.
For example, using the air routes data, we can see that V(44) has four outgoing
routes, and the `union()` correctly yields five results. However, if a `drop()`
is performed after the `union()` only V(44) gets dropped. As a workaround,
doing `union().fold().unfold().drop()` does work and all five vertices get
deleted.
{code:java}
gremlin> g.V().count()
==>3748
gremlin> g.V(44).union(identity(),out()).count()
==>5
gremlin> g.V(44).union(identity(),out()).drop()
// Only one has been dropped
gremlin> g.V().count()
==>3747 {code}
We can see by profiling the two queries that the number of traversers stays at
one, if a drop() step is present, whereas it is five otherwise.
gremlin> g.V(44).union(identity(),out()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[44]) 1
1 0.14348.36
UnionStep([[IdentityStep, EndStep], [VertexStep... 5
5 0.15351.64
IdentityStep 1
1 0.009
EndStep 1
1 0.008
VertexStep(OUT,vertex) 4
4 0.017
EndStep 4
4 0.013
>TOTAL -
- 0.296-gremlin>
g.V(44).union(identity(),out()).drop().profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[44]) 1
1 0.097 1.64
UnionStep([[IdentityStep, EndStep], [VertexStep... 1
1 0.194 3.25
IdentityStep 1
1 0.020
EndStep 1
1 0.0
[jira] [Created] (TINKERPOP-2823) A drop() after a union() does not drop everything found
Kelvin Lawrence created TINKERPOP-2823:
--
Summary: A drop() after a union() does not drop everything found
Key: TINKERPOP-2823
URL: https://issues.apache.org/jira/browse/TINKERPOP-2823
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.6.1
Environment: Gremlin Console, TinkerPop 3.6
Reporter: Kelvin Lawrence
This may be related to https://issues.apache.org/jira/browse/TINKERPOP-2627,
but on the surface appears different.
If a `drop()` step appears after a `union()` step, Gremlin does not drop all of
the vertices that flow out of the `union()`. It only drops one vertex.
For example, using the air routes data, we can see that V(44) has four outgoing
routes, and the `union()` correctly yields five results. However, if a `drop()`
is performed after the `union()` only V(44) gets dropped. As a workaround,
doing `union().fold().unfold().drop()` does work and all five vertices get
deleted.
{code:java}
gremlin> g.V().count()
==>3748
gremlin> g.V(44).union(identity(),out()).count()
==>5
gremlin> g.V(44).union(identity(),out()).drop()
// Only one has been dropped
gremlin> g.V().count()
==>3747 {code}
We can see by profiling the two queries that the number of traversers stays at
one, if a drop() step is present, whereas it is five otherwise.
gremlin> g.V(44).union(identity(),out()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[44]) 1
1 0.14348.36
UnionStep([[IdentityStep, EndStep], [VertexStep... 5
5 0.15351.64
IdentityStep 1
1 0.009
EndStep 1
1 0.008
VertexStep(OUT,vertex) 4
4 0.017
EndStep 4
4 0.013
>TOTAL -
- 0.296-gremlin>
g.V(44).union(identity(),out()).drop().profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[44]) 1
1 0.097 1.64
UnionStep([[IdentityStep, EndStep], [VertexStep... 1
1 0.194 3.25
IdentityStep 1
1 0.020
EndStep 1
1 0.008
VertexStep(OUT,vertex)
0.051
EndStep
0.018
DropStep
5.69595.11
>TOTAL -
- 5.987-
This issue was also reported via a StackOverflow post:
https://stackoverflow.com/questions/74238687/why-does-my-gremlin-query-not-drop-all-the-vertices-i-indicate
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2652) Add TextP.regex to the text predicate set
Kelvin Lawrence created TINKERPOP-2652:
--
Summary: Add TextP.regex to the text predicate set
Key: TINKERPOP-2652
URL: https://issues.apache.org/jira/browse/TINKERPOP-2652
Project: TinkerPop
Issue Type: New Feature
Components: process
Affects Versions: 3.6.0
Reporter: Kelvin Lawrence
We have over the years, going back to a discussion thread from January 2018
[https://lists.apache.org/thread/r76r47jjxmomz9hvsx96www6r8qnh60t] had
discussions of various text predicates that Gremlin lacks but are commonly
found in other query languages such as SPARQL and Cypher. We currently have
some TextP predicates, but not a specific regex one. I propose we add
TextP.regex and for the reference implementation leverage the Java Pattern and
Matcher classes. It may be that other implementations will choose to use a
different REGEX engine but at least this will get the support into the Gremlin
language. As a first pass, I envision this can be something quite simple along
these lines (from a small prototype I put together).
{code:java}
\,,,/
(o o)
-oOOo-(3)-oOOo-
plugin activated: tinkerpop.server
plugin activated: tinkerpop.utilities
plugin activated: tinkerpop.tinkergraph
gremlin> g=traversal().withGraph(TinkerGraph.open())
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV('test').property('k1','I like llamas')
==>v[0]
gremlin> g.V().has('k1',TextP.regex("l[i|x]ke"))
==>v[0]
gremlin> g.V().has('city',TextP.regex("^Dallas"))
==>v[8]
==>v[186] {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2649) Unable to translate gremlin query to java
[
https://issues.apache.org/jira/browse/TINKERPOP-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442838#comment-17442838
]
Kelvin Lawrence commented on TINKERPOP-2649:
In response to your question, [~spmallette] , I like the idea of trending
towards more fine grained, idiomatic translators. Especially as I think we are
well along that road already now with the translator work we did for 3.5
> Unable to translate gremlin query to java
> -
>
> Key: TINKERPOP-2649
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2649
> Project: TinkerPop
> Issue Type: Bug
> Components: translator
>Affects Versions: 3.5.1
>Reporter: Tom Kolanko
>Priority: Minor
>
> _updated description_
>
> In the user interface for Db2 Graph users enter Gremlin queries which get
> submitted as scripts. One feature that we are working on is helping users
> take their queries and use them in their own applications directly, instead
> of using our user interface to run queries. To achieve that we have a
> `translate query` button that shows them their query in the different
> language formats the translator supports. For the most part the Groovy
> translation just works in Java code, however, some data types are problematic.
>
> One unique aspect about Db2 Graph is that all your data is stored in Db2. Our
> implementation takes your Gremlin query and figures out the most optimized
> SQL statements to get the result set. We then execute the SQL statements and
> return the results. On occasion we may need to help Db2 understand how to
> translate a query, for example using java.sql.Timestamp.valueOf('2015-01-01
> 12:05:00') as a filter
>
> When this filter gets translated to Groovy it uses new
> Timestamp(142011390) which is invalid Java. We need to use new
> Timestamp(142011390L)
>
> I'm not sure if there would be other areas where the translated Groovy syntax
> does not work in Java, this is the only example I've found that is problematic
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
