[jira] [Updated] (TINKERPOP-3083) The split() step should provide a way to split an entire string

[Kelvin Lawrence (Jira)]

 [ 
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 (Jira)]

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

[Kelvin Lawrence (Jira)]

 [ 
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 (Jira)]

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 (Jira)]

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)

Re: AW: [VOTE] TinkerPop 3.6.7 Release

[Kelvin Lawrence]

I checked the links, looked over the docs. LGTM.

VOTE +1 

Kelvin 

On Wednesday, April 10, 2024 at 09:46:04 AM CDT, Florian Hockmann 
 wrote:  
 
 I checked the links, skimmed over the docs and executed 
`bin/validate-distribution.sh`. I got one error during the validation where a 
test timed out, but I'm sure that that was caused by my system which is really 
slow in general in the last few days. Everything else passed.

I just found one tiny nit in the upgrade docs: They contain an empty section: 
"Upgrading for Providers". I think that should be removed. 

VOTE +1


-Ursprüngliche Nachricht-
Von: Yang Xia  
Gesendet: Montag, 8. April 2024 23:39
An: dev@tinkerpop.apache.org
Betreff: [VOTE] TinkerPop 3.6.7 Release

Hello,

We are happy to announce that TinkerPop 3.6.7 is ready for release.

The release artifacts can be found at this location:
        https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.7/

The source distribution is provided by:
        apache-tinkerpop-3.6.7-src.zip

Two binary distributions are provided for user convenience:
        apache-tinkerpop-gremlin-console-3.6.7-bin.zip
        apache-tinkerpop-gremlin-server-3.6.7-bin.zip

The GPG key used to sign the release artifacts is available at:
    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
        https://tinkerpop.apache.org/docs/3.6.7/ (user docs)
        https://tinkerpop.apache.org/docs/3.6.7/upgrade/ (upgrade docs)
        https://tinkerpop.apache.org/javadocs/3.6.7/core/ (core javadoc)
        https://tinkerpop.apache.org/javadocs/3.6.7/full/ (full javadoc)
        https://tinkerpop.apache.org/dotnetdocs/3.6.7/ (.NET API docs)
        https://tinkerpop.apache.org/jsdocs/3.6.7/ (Javascript API docs)

The Git tag can be found here:
        https://github.com/apache/tinkerpop/tree/3.6.7

The release notes are available here:
        https://github.com/apache/tinkerpop/blob/3.6.7/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Thursday (April 11, 
2024) at 2:45pm PST (UTC−08:00).

My vote is +1.

Thank you very much,

Yang
*--*
*Yang Xia*

  

Re: AW: [VOTE] TinkerPop 3.7.2 Release

[Kelvin Lawrence]

I downloaded the binary, ran the console, loaded data, ran some queries. LGTM

VOTE +1

Kelvin


 

On Wednesday, April 10, 2024 at 09:46:52 AM CDT, Florian Hockmann 
 wrote:  
 
 I checked the links and skimmed over the docs. Everything looks good to me.

VOTE +1

-Ursprüngliche Nachricht-
Von: Yang Xia  
Gesendet: Mittwoch, 10. April 2024 14:37
An: dev@tinkerpop.apache.org
Betreff: [VOTE] TinkerPop 3.7.2 Release

Hello,

We are happy to announce that TinkerPop 3.7.2 is ready for release.

The release artifacts can be found at this location:
        https://dist.apache.org/repos/dist/dev/tinkerpop/3.7.2/

The source distribution is provided by:
        apache-tinkerpop-3.7.2-src.zip

Two binary distributions are provided for user convenience:
        apache-tinkerpop-gremlin-console-3.7.2-bin.zip
        apache-tinkerpop-gremlin-server-3.7.2-bin.zip

The GPG key used to sign the release artifacts is available at:
    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
        https://tinkerpop.apache.org/docs/3.7.2/ (user docs)
        https://tinkerpop.apache.org/docs/3.7.2/upgrade/ (upgrade docs)
        https://tinkerpop.apache.org/javadocs/3.7.2/core/ (core javadoc)
        https://tinkerpop.apache.org/javadocs/3.7.2/full/ (full javadoc)
        https://tinkerpop.apache.org/dotnetdocs/3.7.2/ (.NET API docs)
        https://tinkerpop.apache.org/jsdocs/3.7.2/ (Javascript API docs)

The Git tag can be found here:
        https://github.com/apache/tinkerpop/tree/3.7.2

The release notes are available here:
        https://github.com/apache/tinkerpop/blob/3.7.2/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Saturday (April 13, 
2024) at 5:45am PT (UTC−08:00).

My vote is +1.

Thank you very much,

Yang
*--*
*Yang Xia*

  

[jira] [Updated] (TINKERPOP-3036) mergeV updating incorrect vertices and other issues

[Kelvin Lawrence (Jira)]

 [ 
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 (Jira)]

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)

Re: AW: [VOTE] TinkerPop 3.5.8 Release

[Kelvin Lawrence]

Apologies for the delay in voting, I have been OOTO. 
VOTE +1
Cheers,
Kelvin 

On Wednesday, November 22, 2023 at 05:06:21 AM CST, Florian Hockmann 
 wrote:  
 
 I reviewed the links and ran validate-distribution.sh without finding any 
issues.

VOTE +1

-Ursprüngliche Nachricht-
Von: Cole Greer  
Gesendet: Dienstag, 21. November 2023 21:04
An: dev@tinkerpop.apache.org
Betreff: RE: [VOTE] TinkerPop 3.5.8 Release

Hi Yang,

Thanks for putting this all together. I reviewed the docs, ran 
validate-distribution.sh, and inspected the artifacts. Everything looks good to 
me.

VOTE +1 (non-binding)

Thanks again,

Cole

On 2023/11/21 01:35:10 Yang Xia wrote:
> Hello,
>
> We are happy to announce that TinkerPop 3.5.8 is ready for release.
>
> The release artifacts can be found at this location:
>        https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.8/
>
> The source distribution is provided by:
>        apache-tinkerpop-3.5.8-src.zip
>
> Two binary distributions are provided for user convenience:
>        apache-tinkerpop-gremlin-console-3.5.8-bin.zip
>        apache-tinkerpop-gremlin-server-3.5.8-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>        https://tinkerpop.apache.org/docs/3.5.8/ (user docs)
>        https://tinkerpop.apache.org/docs/3.5.8/upgrade/ (upgrade docs)
>        https://tinkerpop.apache.org/javadocs/3.5.8/core/ (core javadoc)
>        https://tinkerpop.apache.org/javadocs/3.5.8/full/ (full javadoc)
>        https://tinkerpop.apache.org/dotnetdocs/3.5.8/ (.NET API docs)
>        https://tinkerpop.apache.org/jsdocs/3.5.8/ (Javascript API 
> docs)
>
> The Git tag can be found here:
>        https://github.com/apache/tinkerpop/tree/3.5.8
>
> The release notes are available here:
>        
> https://github.com/apache/tinkerpop/blob/3.5.8/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Thursday 
> (November 23, 2023) at 5:45pm PST (UTC−08:00).
>
> My vote is +1.
>
> Thank you very much,
>
> Yang
> *--*
> *Yang Xia*
>

  

Re: [DISCUSS] Proposal to add possibility to get current server time from traversal.

[Kelvin Lawrence]

I much prefer having datetime() with no parameters return the current server 
date/time. This also keeps the function similar in nature to other query 
languages (e.g. Cypher). I have had several Gremlin users tell me they were 
surprised when it did not already behave that way wen they tried it as it 
seemed "obvious to them" that that is how it would work.
    Cheers, Kelvin
On Tuesday, September 26, 2023 at 07:33:57 PM CDT, Valentyn Kahamlyk 
 wrote:  
 
 Hi all,

Currently, when using a gremlin, there is no way to use the current
server time in requests. This can be convenient for storing the
creation or update date of elements. Also may be useful when examining
query performance.

I propose adding this feature.

There are some ways to implement it
1. Add a new step `currentDateTime()` which will return the current UTC time.
pros: compatible with both bytecode and gremlin
cons: one more step
2. Extend `inject` step to accept some kind of tokens, for example
`inject(DT.now)` or `inject(DT.utcnow)`
pros: can be reused existing step
cons: not feel like gremlin
3. Extend `datetime()` function to return current time without arg.
pros: clean and easy to implement
cons: not compatible with bytecode, what I consider as a blocker

I plan to implement option 1 if there are no objections.

What do you think?

Regards, Valentyn
  

Re: Thoughts on the new concat() step

[Kelvin Lawrence]

Please ignore the Slack link in the post. Somehow my mail editor messed up and 
included that.

On 2023/08/15 15:24:22 Kelvin Lawrence wrote:
> Playing with Gremlin 3.7, and looking at concat() I kind of wish this worked
> 
> g.V(3).as('a').values('code').concat(' is in ', select('a').values('city'))
> 
> rather than having to do
> 
> g.V(3).as('a').values('code').concat(' is in
> ').concat(select('a').values('city'))
> 
> 2:58 <https://amzn-aws.slack.com/archives/D019DRT9KKN/p1691611095325259>
> we do allow
> 
> g.V(3).as('a').values('code').concat(' is in ', 'Austin')  //String...
> 
> so it feels a little unbalanced. I wish I had noticed this before
> but I guess the type signature would have to be object... almost for that
> to work. Perhaps there is a possible compromise where we could do something
> using Traversal... and String...
> 
> -- 
> Cheers, Kelvin
> 

Thoughts on the new concat() step

[Kelvin Lawrence]

Playing with Gremlin 3.7, and looking at concat() I kind of wish this worked

g.V(3).as('a').values('code').concat(' is in ', select('a').values('city'))

rather than having to do

g.V(3).as('a').values('code').concat(' is in
').concat(select('a').values('city'))

2:58 
we do allow

g.V(3).as('a').values('code').concat(' is in ', 'Austin')  //String...

so it feels a little unbalanced. I wish I had noticed this before
but I guess the type signature would have to be object... almost for that
to work. Perhaps there is a possible compromise where we could do something
using Traversal... and String...

-- 
Cheers, Kelvin

[DISCUSS] Add a join() step to the list functions proposal

[Kelvin Lawrence]

In our document [1] where we lay out the vision for new string and list
processing steps, I think perhaps we missed adding a join() step for lists.
We do list a concat() step in the lists column but that is not quite the
same, and also, concat() as specified does not support a local scope
modifier. I envision wanting to do:

```
g.inject([1,2,3,4,5]).join(';')
```
and getting back
```
1;2;3;4;5
```
What do you think?

[1]
https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-3-remove-closures.asciidoc
-- 
Cheers, Kelvin

Re: [VOTE] TinkerPop 3.7.0 Release

[Kelvin Lawrence]

Exciting to see all the new features - thanks for all the work on 3 releases in 
parallel.
VOTE +1
Kelvin  

On Wednesday, August 2, 2023 at 12:51:43 PM CDT, Yang Xia 
 wrote:  
 
 Running validate-distribution.sh on 3.7.0 passed for me with no errors, and
a skim of the links look good. We've got a lot of cool new features
with 3.7.0, looking forward to this new major version! Thanks Cole!

VOTE +1.

Cheers,

Yang

On Mon, Jul 31, 2023 at 10:02 PM Cole Greer
 wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.7.0 is ready for release.
>
> The release artifacts can be found at this location:
>        https://dist.apache.org/repos/dist/dev/tinkerpop/3.7.0/
>
> The source distribution is provided by:
>        apache-tinkerpop-3.7.0-src.zip
>
> Two binary distributions are provided for user convenience:
>        apache-tinkerpop-gremlin-console-3.7.0-bin.zip
>        apache-tinkerpop-gremlin-server-3.7.0-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>        https://tinkerpop.apache.org/docs/3.7.0/ (user docs)
>        https://tinkerpop.apache.org/docs/3.7.0/upgrade/ (upgrade docs)
>        https://tinkerpop.apache.org/javadocs/3.7.0/core/ (core javadoc)
>        https://tinkerpop.apache.org/javadocs/3.7.0/full/ (full javadoc)
>        https://tinkerpop.apache.org/dotnetdocs/3.7.0/ (.NET API docs)
>        https://tinkerpop.apache.org/jsdocs/3.7.0/ (Javascript API docs)
>
> The Git tag can be found here:
>        https://github.com/apache/tinkerpop/tree/3.7.0
>
> The release notes are available here:
>        https://github.com/apache/tinkerpop/blob/3.7.0/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Thursday (August
> 3, 2023) at 9:30PM PDT (04:30AM Aug 4 UTC).
>
> My vote is +1 (non-binding).
>
> Thank you very much,
> Cole
>
  

Re: AW: [VOTE] TinkerPop 3.5.7 Release

[Kelvin Lawrence]

Thanks for the hard work, as always, to get the release done.
VOTE +1

Kelvin 

Kelvin R. Lawrence Round Rock, Texas. http://www.kelvinlawrence.net 

On Thursday, August 3, 2023 at 05:23:19 AM CDT, Florian Hockmann 
 wrote:  
 
 Big thanks also from my side!

I mostly skimmed over the docs and everything looks good.

VOTE +1

-Ursprüngliche Nachricht-
Von: Yang Xia  
Gesendet: Mittwoch, 2. August 2023 19:49
An: dev@tinkerpop.apache.org
Betreff: Re: [VOTE] TinkerPop 3.5.7 Release

Thanks Cole for managing these releases! I've run validate-distribution.sh on 
3.5.7 and it passed with no errors, and the links look good to me.

VOTE +1.

Cheers,

Yang

On Mon, Jul 31, 2023 at 5:22 PM Cole Greer 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.5.7 is ready for release.
>
> The release artifacts can be found at this location:
>        https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.7/
>
> The source distribution is provided by:
>        apache-tinkerpop-3.5.7-src.zip
>
> Two binary distributions are provided for user convenience:
>        apache-tinkerpop-gremlin-console-3.5.7-bin.zip
>        apache-tinkerpop-gremlin-server-3.5.7-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>        https://tinkerpop.apache.org/docs/3.5.7/ (user docs)
>        https://tinkerpop.apache.org/docs/3.5.7/upgrade/ (upgrade docs)
>        https://tinkerpop.apache.org/javadocs/3.5.7/core/ (core javadoc)
>        https://tinkerpop.apache.org/javadocs/3.5.7/full/ (full javadoc)
>        https://tinkerpop.apache.org/dotnetdocs/3.5.7/ (.NET API docs)
>        https://tinkerpop.apache.org/jsdocs/3.5.7/ (Javascript API 
> docs)
>
> The Git tag can be found here:
>        https://github.com/apache/tinkerpop/tree/3.5.7
>
> The release notes are available here:
>        
> https://github.com/apache/tinkerpop/blob/3.5.7/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Thursday 
> (August 3, 2023) at 5:30PM PDT (12:30AM UTC).
>
> My vote is +1 (non-binding).
>
> Thank you very much,
> Cole
>

  

Re: AW: [VOTE] TinkerPop 3.6.5 Release

[Kelvin Lawrence]

Thanks for the hard work, as always, to get the release done.
VOTE +1

Kelvin On Thursday, August 3, 2023 at 05:33:55 AM CDT, Florian Hockmann 
 wrote:  
 
 I skimmed over the docs and everything looks good.

VOTE +1

-Ursprüngliche Nachricht-
Von: Cole Greer  
Gesendet: Mittwoch, 2. August 2023 20:02
An: dev@tinkerpop.apache.org
Betreff: Re: [VOTE] TinkerPop 3.6.5 Release

Thanks Yang,

I’ll be sure to correct that link in the final docs publication.

Regards,

Cole

From: Yang Xia 
Date: Wednesday, August 2, 2023 at 10:50 AM
To: dev@tinkerpop.apache.org 
Subject: Re: [VOTE] TinkerPop 3.6.5 Release I ran validate-distribution.sh on 
3.6.5 and it passed with no errors.  Docs look good, I think there is a minor 
typo in the CHANGELOG hyperlink in the Upgrade docs, it's linking to the 3.5.7 
section instead, but it's very minor and can be easily corrected without 
blocking anything. Thanks Cole!

VOTE +1.

Cheers,

Yang

On Mon, Jul 31, 2023 at 8:46 PM Cole Greer 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.6.5 is ready for release.
>
> The release artifacts can be found at this location:
>        https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.5/
>
> The source distribution is provided by:
>        apache-tinkerpop-3.6.5-src.zip
>
> Two binary distributions are provided for user convenience:
>        apache-tinkerpop-gremlin-console-3.6.5-bin.zip
>        apache-tinkerpop-gremlin-server-3.6.5-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>        https://tinkerpop.apache.org/docs/3.6.5/ (user docs)
>        https://tinkerpop.apache.org/docs/3.6.5/upgrade/ (upgrade docs)
>        https://tinkerpop.apache.org/javadocs/3.6.5/core/ (core javadoc)
>        https://tinkerpop.apache.org/javadocs/3.6.5/full/ (full javadoc)
>        https://tinkerpop.apache.org/dotnetdocs/3.6.5/ (.NET API docs)
>        https://tinkerpop.apache.org/jsdocs/3.6.5/ (Javascript API 
> docs)
>
> The Git tag can be found here:
>        https://github.com/apache/tinkerpop/tree/3.6.5
>
> The release notes are available here:
>        
> https://github.com/apache/tinkerpop/blob/3.6.5/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Thursday 
> (August 3, 2023) at 9:00PM PDT (04:00AM Aug 4 UTC).
> My vote is +1 (non-binding).
>
> Thank you very much,
> Cole
>

  

[jira] [Updated] (TINKERPOP-2957) mergeV with sideEffect not correctly updating properties

[Kelvin Lawrence (Jira)]

 [ 
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 (Jira)]

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)

Re: [VOTE] TinkerPop 3.6.4 Release

[Kelvin Lawrence]

This fast turnaround release fixes an issue that at least two people I am aware 
of have run into (Regex in Bytecode from the Java client).
VOTE +1
-  Kelvin


On Monday, May 15, 2023 at 01:15:19 PM CDT, Cole Greer 
 wrote:  
 
 Thanks for putting together another release Yang.

I checked the links, skimmed through the docs, checked LICENSE/NOTICE files, 
and ran validate-distribution.sh and everything looks good to me.

One small noteworthy item I saw is that the FUTURE docs 
(https://tinkerpop.apache.org/docs/3.6.4/dev/future/) still reference 3.7.x as 
having a 2022 Q4 target and the existing proposals for 3.7 features are not 
included in this doc. This is a consequence of our tendency to only merge 
proposals into the master branch.  I would suggest that going forward we start 
merging FUTURE docs updates and proposals into the dev branches such that 
https://tinkerpop.apache.org/docs/current/dev/future/ will always reflect the 
latest proposals. I don’t see this as a blocker for this release.

VOTE +1 (non-binding)

Regards,

Cole Greer

From: Florian Hockmann 
Date: Sunday, May 14, 2023 at 11:59 PM
To: dev@tinkerpop.apache.org 
Subject: AW: [VOTE] TinkerPop 3.6.4 Release
I checked the links, and everything looks good.

VOTE +1

-Ursprüngliche Nachricht-
Von: Yang Xia 
Gesendet: Sonntag, 14. Mai 2023 00:55
An: dev@tinkerpop.apache.org
Betreff: [VOTE] TinkerPop 3.6.4 Release

Hello,

We are happy to announce that TinkerPop 3.6.4 is ready for release.

The release artifacts can be found at this location:
        https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.4/

The source distribution is provided by:
        apache-tinkerpop-3.6.4-src.zip

Two binary distributions are provided for user convenience:
        apache-tinkerpop-gremlin-console-3.6.4-bin.zip
        apache-tinkerpop-gremlin-server-3.6.4-bin.zip

The GPG key used to sign the release artifacts is available at:
    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
        https://tinkerpop.apache.org/docs/3.6.4/ (user docs)
        https://tinkerpop.apache.org/docs/3.6.4/upgrade/ (upgrade docs)
        https://tinkerpop.apache.org/javadocs/3.6.4/core/ (core javadoc)
        https://tinkerpop.apache.org/javadocs/3.6.4/full/ (full javadoc)
        https://tinkerpop.apache.org/dotnetdocs/3.6.4/ (.NET API docs)
        https://tinkerpop.apache.org/jsdocs/3.6.4/ (Javascript API docs)

The Git tag can be found here:
        https://github.com/apache/tinkerpop/tree/3.6.4

The release notes are available here:
        https://github.com/apache/tinkerpop/blob/3.6.4/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Tuesday (May 16,
2023) at 16:00 PDT(UTC-7)

My vote is +1.

Thank you very much,

Yang
*--*
*Yang Xia*
  

Re: AW: [VOTE] TinkerPop 3.5.6 Release

[Kelvin Lawrence]

There are a number of important performance and correctness fixes in this 
release as well as some important bug fixes - including one I'm particularly 
keen on regarding the math() step . VOTE +1 - Kelvin

 

On Wednesday, May 3, 2023 at 09:59:53 AM CDT, Florian Hockmann 
 wrote:  
 
 Thanks for taking care of the releases again, Yang. And of course, also thanks 
to everyone who contributed to this release! There are definitely some 
important fixes in it.

I checked the links, skimmed over the docs and everything looks good to me.

VOTE +1

-Ursprüngliche Nachricht-
Von: Yang Xia  
Gesendet: Dienstag, 2. Mai 2023 05:40
An: dev@tinkerpop.apache.org
Betreff: [VOTE] TinkerPop 3.5.6 Release

Hello,

We are happy to announce that TinkerPop 3.5.6 is ready for release.

The release artifacts can be found at this location:
        https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.6/

The source distribution is provided by:
        apache-tinkerpop-3.5.6-src.zip

Two binary distributions are provided for user convenience:
        apache-tinkerpop-gremlin-console-3.5.6-bin.zip
        apache-tinkerpop-gremlin-server-3.5.6-bin.zip

The GPG key used to sign the release artifacts is available at:
    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
        https://tinkerpop.apache.org/docs/3.5.6/ (user docs)
        https://tinkerpop.apache.org/docs/3.5.6/upgrade/ (upgrade docs)
        https://tinkerpop.apache.org/javadocs/3.5.6/core/ (core javadoc)
        https://tinkerpop.apache.org/javadocs/3.5.6/full/ (full javadoc)
        https://tinkerpop.apache.org/dotnetdocs/3.5.6/ (.NET API docs)
        https://tinkerpop.apache.org/jsdocs/3.5.6/ (Javascript API docs)

The Git tag can be found here:
        https://github.com/apache/tinkerpop/tree/3.5.6

The release notes are available here:
        https://github.com/apache/tinkerpop/blob/3.5.6/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Thursday (May 4,
2023) at 21:00 PDT(UTC-7).

My vote is +1.

Thank you very much,

Yang
*--*
*Yang Xia*

  

Re: [VOTE] TinkerPop 3.6.3 Release

[Kelvin Lawrence]

There are a number of important performance and correctness fixes in this 
release as well as some important bug fixes. VOTE +1 - Kelvin 

On Wednesday, May 3, 2023 at 04:57:10 PM CDT, Cole Greer 
 wrote:  
 
 Thanks for putting together these releases Yang.

I’ve run validate-distribution.sh for both 3.5.6 and 3.6.3 as well as quickly 
scanning through the docs for both. That all looks good to me. The one concern 
that I spotted was there appears to be some missing items in the NOTICE and 
licenses for the console and server. Objenesis and byte-buddy both need NOTICE 
entries and ANTLR should be included in the licenses directory. After further 
inspection these are not new issues. The NOTICE issues seem to have first 
appeared in 3.5.4 and the missing ANTLR license dates back to 3.5.2. I don’t 
see these issues being significant enough to abort the release especially 
considering they’ve remained undiscovered for so long. I would be happy to 
submit a PR correcting these issues once the branches reopen after release.

I will give a non binding VOTE +1 for both 3.5.6 and 3.6.3.

Regards,

Cole Greer

From: Yang Xia 
Date: Tuesday, May 2, 2023 at 8:25 AM
To: dev@tinkerpop.apache.org 
Subject: [VOTE] TinkerPop 3.6.3 Release
Hello,

We are happy to announce that TinkerPop 3.6.3 is ready for release.

The release artifacts can be found at this location:
        https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.3/

The source distribution is provided by:
        apache-tinkerpop-3.6.3-src.zip

Two binary distributions are provided for user convenience:
        apache-tinkerpop-gremlin-console-3.6.3-bin.zip
        apache-tinkerpop-gremlin-server-3.6.3-bin.zip

The GPG key used to sign the release artifacts is available at:
    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
        https://tinkerpop.apache.org/docs/3.6.3/ (user docs)
        https://tinkerpop.apache.org/docs/3.6.3/upgrade/ (upgrade docs)
        https://tinkerpop.apache.org/javadocs/3.6.3/core/ (core javadoc)
        https://tinkerpop.apache.org/javadocs/3.6.3/full/ (full javadoc)
        https://tinkerpop.apache.org/dotnetdocs/3.6.3/ (.NET API docs)
        https://tinkerpop.apache.org/jsdocs/3.6.3/ (Javascript API docs)

The Git tag can be found here:
        https://github.com/apache/tinkerpop/tree/3.6.3

The release notes are available here:
        https://github.com/apache/tinkerpop/blob/3.6.3/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Friday (May 5,
2023) at 8:30 PDT(UTC-7)

My vote is +1.

Thank you very much,

Yang
*--*
*Yang Xia*
  

[jira] [Commented] (TINKERPOP-2906) Query using coalesce adding the same vertex twice

[Kelvin Lawrence (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Kelvin Lawrence (Jira)]

 [ 
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]gr

[jira] [Updated] (TINKERPOP-2906) Query using coalesce adding the same vertex twice

[Kelvin Lawrence (Jira)]

 [ 
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

[jira] [Created] (TINKERPOP-2906) Query using coalesce adding the same vertex twice

[Kelvin Lawrence (Jira)]

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)

Re: [DISCUSS] Union of Traversals

[Kelvin Lawrence]

I think making union() a start step makes a lot of sense. It enables several 
useful query patterns. 
Cheers, Kelvin  

On Wednesday, February 22, 2023 at 06:33:25 AM CST, Martin 
 wrote:  
 
 Dear TinkerPop developers!

I was recently faced with the task to create the union of a given list 
of (anonymous) traversals, each of which had defined start and end 
steps. The intended effect was similar to a "UNION ALL" in SQL. This 
turned out to be tricky to achieve in Gremlin. Please find the details, 
the workaround, and my proposed solution (having "union" as a traversal 
start step) here:

https://issues.apache.org/jira/browse/TINKERPOP-2873?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17692159#comment-17692159

I'm happy to discuss this matter. Thank you for your consideration.

Kind regards,

Martin Häusler

  

[jira] [Updated] (TINKERPOP-2870) mergeV requires key of 'new' to be quoted

[Kelvin Lawrence (Jira)]

 [ 
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

[Kelvin Lawrence (Jira)]

 [ 
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 (Jira)]

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)

Re: [VOTE] TinkerPop 3.5.5 Release

[Kelvin Lawrence]

VOTE +1
-- Kelvin


On Thursday, January 26, 2023 at 05:44:29 AM CST, Divij Vaidya 
 wrote:  
 
 Thank you for clarifying my questions Yang.

We have the following problems with our release process today:
1. The binaries that we release for python and .Net are not voted-on during
the release votes. Hence, there is no way for a user to validate that the
binary in PyPi or nuGet is actually generated from the source code that was
voted on.
2. The symlink bug that I pointed above will cause problems for folks who
download the source code zip and try to run gremlin.sh

Both these problems have been prevalent for earlier releases as well and
hence, I don't want to block this release over these gaps. But we should
try to fix these problems before the next release.

I have created the following JIRA(s) to track these two problems:
https://issues.apache.org/jira/browse/TINKERPOP-2860
https://issues.apache.org/jira/browse/TINKERPOP-2861


VOTE +1 (binding)

--
Divij Vaidya



On Wed, Jan 25, 2023 at 12:01 AM Yang Xia 
wrote:

> Hi Divij,
>
> Thank you for your feedback! To address your questions:
>
> 1. I believe that we should probably add UserAgent and the changes in
> > connection timeout to the upgrade documentation. They both require user
> > side code changes (since they add new configuration or modify the
> behaviour
> > of existing one) and hence, users must be aware of them while upgrading.
> > What do you think?
>
>
> I think it is a valid point to add some information about it in the Upgrade
> docs, but perhaps it is something we could add and update post release? It
> is a small documentation change that likely should not block release. In
> addition, these changes are captured in the CHANGELOG, which is a source of
> information users use as well.
>
>
> 2. Apart from the server and the console binary, we are also releasing a
> > go-client, python and a .Net client binary as well. Right? Could you
> please
> > provide links to the client binaries as well so that we can validate the
> > signatures on those?
>
>
> For the GLVs, as there are no binaries for gremlin-go (its release is
> integrated with GitHub) and no staging of artifacts for other package
> managers like Sonatype, any convenience binaries for those languages are
> not produced until after the VOTE, when we have agreed to deploy the
> official Apache release.
>
>
> 3.  The zip binary (apache-tinkerpop-3.5.5-src.zip) has some symbolic links
> > that look incorrect (see below). This might require fixing before we
> > release.
>
>
> This is an interesting catch. I see the symlinks as relative paths in my
> local repository (via ls -la and readlink) and also on GitHub, so I think
> it has to do with how maven handles symlinks on macOS when assembling
> source files. I’m surprised that bin/validate-distribution.sh did not catch
> that. Is there a tool that you used? Perhaps we should update the script to
> include symlink checking.
> It’s unfortunate we have this small bug but I don’t think it’s bad enough
> to warrant redoing both releases, unless we have folks who intend to change
> their votes as a result of this find.
>
> Regards,
>
> Yang
>
> *--*
> *Yang Xia*
> Software Engineer
> Bit Quill Technologies Inc.
> ya...@bitquilltech.com
> https://www.bitquill.com
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information.  Any unauthorized review,
> use, disclosure, or distribution is prohibited.  If you are not the
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message.  Thank you.
>
>
> On Tue, Jan 24, 2023 at 2:03 AM Divij Vaidya 
> wrote:
>
> > Thank you Yang for taking ownership of this release.
> >
> > 1. I believe that we should probably add UserAgent and the changes in
> > connection timeout to the upgrade documentation. They both require user
> > side code changes (since they add new configuration or modify the
> behaviour
> > of existing one) and hence, users must be aware of them while upgrading.
> > What do you think?
> >
> > 2. Apart from the server and the console binary, we are also releasing a
> > go-client, python and a .Net client binary as well. Right? Could you
> please
> > provide links to the client binaries as well so that we can validate the
> > signatures on those?
> >
> > 3.  The zip binary (apache-tinkerpop-3.5.5-src.zip) has some symbolic
> links
> > that look incorrect (see below). This might require fixing before we
> > release.
> >
> > ```
> > finishing deferred symbolic links:
> >  tinkerpop-3.5.5/bin/gremlin.sh ->
> >
> >
> /Users/yangx/Repos/maintinkerpop/tinkerpop/./bin/../gremlin-console/bin/gremlin.sh
> >  tinkerpop-3.5.5/gremlin-console/bin/gremlin.sh ->
> >
> >
> /Users/yangx/Repos/maintinkerpop/tinkerpop/./gremlin-console/bin/../target/apache-tinkerpop-gremlin-console-3.5.5-standalone/bin/gremlin.sh
> > ```
> >
> > 4. I have verified the following:
> >
> > 4.1 Download links 

Re: [VOTE] TinkerPop 3.6.2 Release

[Kelvin Lawrence]

VOTE +1


-- Kelvin 

On Thursday, January 26, 2023 at 05:46:53 AM CST, Divij Vaidya 
 wrote:  
 
 I have created the following JIRA(s) to track these two problems I found
during the release validation:
https://issues.apache.org/jira/browse/TINKERPOP-2860
https://issues.apache.org/jira/browse/TINKERPOP-2861

Both these problems exist in prior releases and are not blocker for this
release.

VOTE +1 (binding)

--
Divij Vaidya



On Tue, Jan 24, 2023 at 11:06 AM Divij Vaidya 
wrote:

> I have the same comments as the 3.5.5 release. Binary contains incorrect
> symlinks and we probably need to add binaries for other language clients
> for release validation here.
>
> --
> Divij Vaidya
>
>
>
> On Tue, Jan 24, 2023 at 2:42 AM David Bechberger 
> wrote:
>
>> Looks good to me
>>
>> VOTE +1 (non-binding)
>>
>> On Mon, Jan 23, 2023 at 10:29 AM Ken Hu 
>> wrote:
>>
>> > Thanks Yang. This looks good to me.
>> >
>> > VOTE +1 (non-binding)
>> >
>> > On Mon, Jan 23, 2023 at 10:05 AM Cole Greer
>> >  wrote:
>> >
>> > > Thanks for putting this all together Yang. I’ve dug through the docs
>> and
>> > > artifacts and it all looks good to me.
>> > >
>> > > VOTE +1 (non-binding)
>> > >
>> > > Regards,
>> > >
>> > > Cole Greer
>> > >
>> > >
>> > > From: Valentyn Kahamlyk 
>> > > Date: Monday, January 23, 2023 at 9:16 AM
>> > > To: dev@tinkerpop.apache.org 
>> > > Subject: Re: [VOTE] TinkerPop 3.6.2 Release
>> > > Yang, thank you for preparing the release!
>> > >
>> > > VOTE +1 (non-binding)
>> > >
>> > > On Mon, Jan 23, 2023 at 8:16 AM Florian Hockmann <
>> f...@florian-hockmann.de
>> > >
>> > > wrote:
>> > >
>> > > > I had the same problem with bin/validate-distribution.sh as in the
>> > other
>> > > > thread, but again, this shouldn't be a problem for the release
>> > process. I
>> > > > again skimmed over the docs and everything looks good to me.
>> > > >
>> > > > VOTE +1
>> > > >
>> > > > -Ursprüngliche Nachricht-
>> > > > Von: Yang Xia 
>> > > > Gesendet: Samstag, 21. Januar 2023 06:27
>> > > > An: dev@tinkerpop.apache.org
>> > > > Betreff: [VOTE] TinkerPop 3.6.2 Release
>> > > >
>> > > > Hello,
>> > > >
>> > > > We are happy to announce that TinkerPop 3.6.2 is ready for release.
>> > > >
>> > > > The release artifacts can be found at this location:
>> > > >        https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.2/
>> > > >
>> > > > The source distribution is provided by:
>> > > >        apache-tinkerpop-3.6.2-src.zip
>> > > >
>> > > > Two binary distributions are provided for user convenience:
>> > > >        apache-tinkerpop-gremlin-console-3.6.2-bin.zip
>> > > >        apache-tinkerpop-gremlin-server-3.6.2-bin.zip
>> > > >
>> > > > The GPG key used to sign the release artifacts is available at:
>> > > >    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>> > > >
>> > > > The online docs can be found here:
>> > > >        https://tinkerpop.apache.org/docs/3.6.2/ (user docs)
>> > > >        https://tinkerpop.apache.org/docs/3.6.2/upgrade/ (upgrade
>> > docs)
>> > > >        https://tinkerpop.apache.org/javadocs/3.6.2/core/ (core
>> > javadoc)
>> > > >        https://tinkerpop.apache.org/javadocs/3.6.2/full/ (full
>> > javadoc)
>> > > >        https://tinkerpop.apache.org/dotnetdocs/3.6.2/ (.NET API
>> docs)
>> > > >        https://tinkerpop.apache.org/jsdocs/3.6.2/ (Javascript API
>> > docs)
>> > > >
>> > > > The Git tag can be found here:
>> > > >        https://github.com/apache/tinkerpop/tree/3.6.2
>> > > >
>> > > > The release notes are available here:
>> > > >
>> > > https://github.com/apache/tinkerpop/blob/3.6.2/CHANGELOG.asciidoc
>> > > >
>> > > > Please note that you may get "rm: cannot remove" permission errors
>> when
>> > > > running bin/validate-distribution.sh, which we have made a note to
>> fix
>> > > > after the release. The temporary solution is to run this script with
>> > sudo
>> > > > or editing the script to add sudo to "rm" commands.
>> > > >
>> > > > The [VOTE] will be open for the next 72 hours --- closing Monday
>> > (January
>> > > > 23, 2023) at 9:30pm PST (UTC−08:00).
>> > > >
>> > > > My vote is +1.
>> > > >
>> > > > Thank you very much,
>> > > >
>> > > > Yang Xia
>> > > > *--*
>> > > > *Yang Xia*
>> > > > Software Engineer
>> > > > Bit Quill Technologies Inc.
>> > > > ya...@bitquilltech.com
>> > > > https://www.bitquill.com
>> > > >
>> > > > This email message is for the sole use of the intended recipient(s)
>> and
>> > > > may contain confidential and privileged information.  Any
>> unauthorized
>> > > > review, use, disclosure, or distribution is prohibited.  If you are
>> not
>> > > the
>> > > > intended recipient, please contact the sender by reply email and
>> > destroy
>> > > > all copies of the original message.  Thank you.
>> > > >
>> > > >
>> > >
>> >
>>
>
  

[jira] [Updated] (TINKERPOP-2856) math() step fails if variable name contains a keyword

[Kelvin Lawrence (Jira)]

 [ 
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 (Jira)]

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

[Kelvin Lawrence (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

Re: [DISCUSS] Proposal to add new options to mergeE

[Kelvin Lawrence]

Thanks for the detailed analysis Mike. It's great to get this kind of early 
feedback on new steps. Given my sense is that most databases have yet to 
implement support for mergeV and mergeV, if there are things we missed in the 
original design, that make the use of these steps easier, then it makes sense 
to make those changes ASAP.
Many users today struggle with the coalesce upsert patterns and struggle 
equally with map injection variations of the same tasks. We want the mergeV and 
mergE steps to be able to replace as many of those other query patterns as 
possible.
So, +1 from me on the changes you propose.
Cheers,Kelvin 

On Friday, December 16, 2022 at 08:35:10 AM CST, Mike Personick 
 wrote:  
 
 As part of early feedback on mergeV/E, users have pointed out one major use
case that mergeE cannot support in its current form:

g.V()
    .hasLabel("x").has("uid", "01")
    .outE("x")
    .where(inV().hasLabel("x").has("uid", "02"))
    .fold()
    .coalesce(
        unfold(),
        addE("y")
            .from(V().hasLabel("x").has("uid", "01"))
            .to(V().hasLabel("x").has("uid", "02"))
    )

This query is not translatable into mergeE, because the Vertex IDs for the
from and to vertices are not known statically, but rather computed
dynamically at runtime. Late binding for the Direction.IN/OUT vertex IDs is
not currently supported by mergeE.

We can accomplish late binding on one the other vertex using upstream input
(g.V()mergeE()) but this still leaves a gap for discovery of both sides
of the edge, except in cases of self-edges.

We propose breaking the current relationship between mergeE and its
upstream input (making it match the relationship with upstream input for
mergeV), and adding two new option values for mergeE where from and to
vertices can be discovered:

g.mergeE([T.label: "y", OUT: Merge.outV, IN: Merge:inV])
 .option(Merge.outV, [T.label: "x", "uid": "01"])
 .option(Merge.inV, [T.label: "x", "uid": "02"])

The Merge.outV/inV tokens will be used as option keys, and will also serve
as placeholders inside the mergeE argument maps for late binding of the
IN/OUT vertex IDs. Using Merge.outV (inV) for any value other than the
Direction.OUT
(IN) key in the merge argument maps will be disallowed.

We propose adding these new tokens and mergeE options to version 3.6.2.

We will assume a lazy consensus and proceed with these changes if there are
no objections by Wednesday 12/23/22 at 5pm ET.
  

[jira] [Updated] (TINKERPOP-2823) A drop() after a union() does not drop everything found

[Kelvin Lawrence (Jira)]

 [ 
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.00

[jira] [Updated] (TINKERPOP-2823) A drop() after a union() does not drop everything found

[Kelvin Lawrence (Jira)]

 [ 
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 

[jira] [Created] (TINKERPOP-2823) A drop() after a union() does not drop everything found

[Kelvin Lawrence (Jira)]

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)

Re: AW: [DISCUSS] Next release, code freeze etc.

[Kelvin Lawrence]

Hello everyone, now that the 3.5.4 and 3.6.1 release are out we are no longer 
in code freeze.
The release branches are now back in SNAPSHOT mode.
Development can recommence on the 3.5-dev and 3.6-dev lines
Cheers,Kelvin.


On Monday, July 4, 2022 at 03:29:33 AM CDT, Florian Hockmann 
 wrote:  
 
 Thanks for starting the discussion on this, Kelvin! Our last releases were 
also 3 months ago which is roughly the release cadence that we aim for and yes, 
getting an official release of the Go client out alone is already a good reason 
for a release.
If nobody sees any import issues that are still open, then we can start code 
freeze quite soon from my side.

-Ursprüngliche Nachricht-
Von: Kelvin Lawrence  
Gesendet: Freitag, 1. Juli 2022 21:29
An: dev@tinkerpop.apache.org
Betreff: [DISCUSS] Next release, code freeze etc.


We have some useful (and sizable) contributions now merged into the dev 
branches for 3.5.x and 3.6.x. These include the "ready for GA" version of the 
Gremlin Go client, and the work to add Graph Binary support to the 
Node/Javascript client. It feels like it would be good to cut a release soon to 
get these two items, as well as other features and fixes out in an official 
version. I have had a few folks tell me they would like to use the Go client, 
but that they would like to see it be part of an official release.
What do people think?
Cheers,Kelvin

  

Apache TinkerPop 3.5.4 Released: The Sleeping Gremlin: No. 18 Entr’acte Symphonique

[Kelvin Lawrence]

Hello,

Apache TinkerPop 3.5.4 has just been released.
- Gremlin Go is officially available starting with this release.
- Graph Binary support is added to the gremlin-javascript client.
- Please see the upgrade documentation for details of other changes.

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.5.4/apache-tinkerpop-gremlin-console-3.5.4-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.5.4/apache-tinkerpop-gremlin-server-3.5.4-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.5.4/apache-tinkerpop-3.5.4-src.zip

The online docs can be found here:

https://tinkerpop.apache.org/docs/3.5.4/reference/ (user docs)
https://tinkerpop.apache.org/docs/3.5.4/upgrade/#_tinkerpop_3.5.4 (upgrade
docs)
https://tinkerpop.apache.org/javadocs/3.5.4/core/ (core javadoc)
https://tinkerpop.apache.org/javadocs/3.5.4/full/ (full javadoc)
https://tinkerpop.apache.org/dotnetdocs/3.5.4/ (.NET API docs)
https://tinkerpop.apache.org/jsdocs/3.5.4/ (Javascript API docs)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.5.4/CHANGELOG.asciidoc#release-3.5.4

The Central Maven repo has sync'd as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.5.4/

Python artifacts are available in pypi:

https://pypi.python.org/pypi/gremlinpython/3.5.4

.NET artifacts are available in NuGet:

https://www.nuget.org/packages/Gremlin.Net/3.5.4
https://www.nuget.org/packages/Gremlin.Net.Template/3.5.4

Javascript artifacts are available in npm:

https://www.npmjs.com/package/gremlin/v/3.5.4

Go artifacts available in pkg.go.dev :

https://pkg.go.dev/github.com/apache/tinkerpop/gremlin-go/v3@v3.5.4/driver

Gremlint is available in npm:

https://www.npmjs.com/package/gremlint/v/3.5.4

Docker images for Gremlin Console and Gremlin Server can be found on Docker
Hub:

https://hub.docker.com/u/tinkerpop/

[image: image.png]

Subject: [RESULT][VOTE] TinkerPop 3.6.1 Release

[Kelvin Lawrence]

 This vote is now closed with a total of 3 +1s, no +0s and no -1s.

The results are: BINDING VOTES: +1 (3 Divij Vaidya, Florian Hockmann,
Kelvin Lawrence) 0 (0)
-1 (0) NON-BINDING VOTES: +1 (0) 0 (0) -1 (0) Thank you very much, Kelvin
Lawrence

[RESULT][VOTE] TinkerPop 3.5.4 Release

[Kelvin Lawrence]

This vote is now closed with a total of 3 +1s, no +0s and no -1s.

The results are: BINDING VOTES: +1 (3 -- Divij Vaidya, Florian Hockmann,
Kelvin Lawrence) 0 (0) -1 (0) NON-BINDING VOTES: +1 (0) 0 (0) -1 (0) Thank
you very much, Kelvin Lawrence
--

[VOTE] TinkerPop 3.6.1 Release

[Kelvin Lawrence]

Hello,

We are happy to announce that TinkerPop 3.6.1 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.1/

The source distribution is provided by:
apache-tinkerpop-3.6.1-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.6.1-bin.zip
apache-tinkerpop-gremlin-server-3.6.1-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
https://tinkerpop.apache.org/docs/3.6.1/ (user docs)
https://tinkerpop.apache.org/docs/3.6.1/upgrade/ (upgrade docs)
https://tinkerpop.apache.org/javadocs/3.6.1/core/ (core javadoc)
https://tinkerpop.apache.org/javadocs/3.6.1/full/ (full javadoc)
https://tinkerpop.apache.org/dotnetdocs/3.6.1/ (.NET API docs)
https://tinkerpop.apache.org/jsdocs/3.6.1/ (Javascript API docs)

The Git tag can be found here:
https://github.com/apache/tinkerpop/tree/3.6.1

The release notes are available here:
https://github.com/apache/tinkerpop/blob/3.6.1/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Sunday (July
24th 2022) at 21:00 GMT (16:00 CDT)

My vote is +1.

Thank you very much,
Kelvin Lawrence

Subject: [VOTE] TinkerPop 3.5.4 Release

[Kelvin Lawrence]

Hello,

We are happy to announce that TinkerPop 3.5.4 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.4/

The source distribution is provided by:
apache-tinkerpop-3.5.4-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.5.4-bin.zip
apache-tinkerpop-gremlin-server-3.5.4-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
https://tinkerpop.apache.org/docs/3.5.4/ (user docs)
https://tinkerpop.apache.org/docs/3.5.4/upgrade/ (upgrade docs)
https://tinkerpop.apache.org/javadocs/3.5.4/core/ (core javadoc)
https://tinkerpop.apache.org/javadocs/3.5.4/full/ (full javadoc)
https://tinkerpop.apache.org/dotnetdocs/3.5.4/ (.NET API docs)
https://tinkerpop.apache.org/jsdocs/3.5.4/ (Javascript API docs)

The Git tag can be found here:
https://github.com/apache/tinkerpop/tree/3.5.4

The release notes are available here:
https://github.com/apache/tinkerpop/blob/3.5.4/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Saturday (July
23rd 2022) at 21:00 GMT (16:00 US CDT)

My vote is +1.

Thank you very much,
Kelvin Lawrence

RE: [DISCUSS] Next release, code freeze etc.

[Kelvin Lawrence]

Thanks Lyndon – may take you up on that, but hopefully everything will just 
work  

Cheers,
Kelvin

Kelvin R. Lawrence


From: Lyndon Bauto
Sent: Monday, July 18, 2022 6:48 PM
To: dev@tinkerpop.apache.org
Subject: Re: [DISCUSS] Next release, code freeze etc.

I can make some time to help with the official gremlin-go release if you
need any assistance, I think it should be straightforward, but I am happy
to help.

On Mon, Jul 18, 2022 at 3:43 PM Kelvin Lawrence 
wrote:

> Hi everyone, still learning the ropes a little in terms of how things work
> with getting releases done. Having suggested we should cut a release soon,
> I'm also happy to help get it done. I realize I should have already, but
> did not, send a code freeze email last week. It seems like everyone was
> operating like we are frozen though, so I will proceed with release this
> week unless anyone objects . I've asked Stephen to help me prepare the
> artifacts as I haven't done this before and will need help!
> Hopefully we can have a vote thread soon for 3.5.4.
> Cheers,Kelvin
>
>
> On Monday, July 4, 2022 at 06:55:05 AM CDT, Roi Martin <
> jroi.mar...@gmail.com> wrote:
>
>  On Mon, Jul 04, 2022 at 10:29:29AM +0200, Florian Hockmann wrote:
> > Thanks for starting the discussion on this, Kelvin! Our last releases
> were also 3 months ago which is roughly the release cadence that we aim for
> and yes, getting an official release of the Go client out alone is already
> a good reason for a release.
> > If nobody sees any import issues that are still open, then we can start
> code freeze quite soon from my side.
>
> Hi,
>
> I'm a newcomer to this project to have much weight in my opinion. However,
> regarding gremlin-go, I think it could be important to close the following
> issues first:
>
> Race condition issues:
> - gremlin-go: fix deadlock on (*DriverRemoteConnection).Close
>   https://github.com/apache/tinkerpop/pull/1734
> - gremlin-go: fix data race on serializers and deserializers initialization
>   https://github.com/apache/tinkerpop/pull/1744
> - gremlin-go: fix data race on localizer initialization
>   https://github.com/apache/tinkerpop/pull/1745
>
> Usability issues:
> - Cast Times serialization to int in Gremlin-Go
>   https://github.com/apache/tinkerpop/pull/1743
>
> Also, regarding gremlin-server, I faced the following issues while using
> gremlin-go:
>
> - gremlin-server does not reply with a timeout response to all timed out
> requests
>   https://issues.apache.org/jira/browse/TINKERPOP-2769
> - Race condition during script creation when using UnifiedChannelizer
>   https://issues.apache.org/jira/browse/TINKERPOP-2765
>
> You might want to give them a look to see if they could be a blocker.
>
> Thanks!
>
> Best regards,
> Roi
>



-- 

*Lyndon Bauto*
*Senior Software Engineer*
*Aerospike, Inc.*
www.aerospike.com
lba...@aerospike.com

Re: [DISCUSS] Next release, code freeze etc.

[Kelvin Lawrence]

Hi everyone, still learning the ropes a little in terms of how things work with 
getting releases done. Having suggested we should cut a release soon, I'm also 
happy to help get it done. I realize I should have already, but did not, send a 
code freeze email last week. It seems like everyone was operating like we are 
frozen though, so I will proceed with release this week unless anyone objects . 
I've asked Stephen to help me prepare the artifacts as I haven't done this 
before and will need help!
Hopefully we can have a vote thread soon for 3.5.4.
Cheers,Kelvin
 

On Monday, July 4, 2022 at 06:55:05 AM CDT, Roi Martin 
 wrote:  
 
 On Mon, Jul 04, 2022 at 10:29:29AM +0200, Florian Hockmann wrote:
> Thanks for starting the discussion on this, Kelvin! Our last releases were 
> also 3 months ago which is roughly the release cadence that we aim for and 
> yes, getting an official release of the Go client out alone is already a good 
> reason for a release.
> If nobody sees any import issues that are still open, then we can start code 
> freeze quite soon from my side.

Hi,

I'm a newcomer to this project to have much weight in my opinion. However,
regarding gremlin-go, I think it could be important to close the following
issues first:

Race condition issues:
- gremlin-go: fix deadlock on (*DriverRemoteConnection).Close
  https://github.com/apache/tinkerpop/pull/1734
- gremlin-go: fix data race on serializers and deserializers initialization
  https://github.com/apache/tinkerpop/pull/1744
- gremlin-go: fix data race on localizer initialization
  https://github.com/apache/tinkerpop/pull/1745

Usability issues:
- Cast Times serialization to int in Gremlin-Go
  https://github.com/apache/tinkerpop/pull/1743

Also, regarding gremlin-server, I faced the following issues while using
gremlin-go:

- gremlin-server does not reply with a timeout response to all timed out 
requests
  https://issues.apache.org/jira/browse/TINKERPOP-2769
- Race condition during script creation when using UnifiedChannelizer
  https://issues.apache.org/jira/browse/TINKERPOP-2765

You might want to give them a look to see if they could be a blocker.

Thanks!

Best regards,
Roi
  

[DISCUSS] Next release, code freeze etc.

[Kelvin Lawrence]

We have some useful (and sizable) contributions now merged into the dev 
branches for 3.5.x and 3.6.x. These include the "ready for GA" version of the 
Gremlin Go client, and the work to add Graph Binary support to the 
Node/Javascript client. It feels like it would be good to cut a release soon to 
get these two items, as well as other features and fixes out in an official 
version. I have had a few folks tell me they would like to use the Go client, 
but that they would like to see it be part of an official release.
What do people think?
Cheers,Kelvin

Re: [VOTE] TinkerPop 3.6.0 Release

[Kelvin Lawrence]

I'm really excited about this release - it adds some of the most requested 
features to Gremlin.
VOTE +1

 

On Tuesday, April 5, 2022, 04:47:32 PM CDT, Lyndon Bauto 
 wrote:  
 
 VOTE+1

On Tue, Apr 5, 2022 at 2:02 PM Stephen Mallette 
wrote:

> We are happy to announce that TinkerPop 3.6.0 is ready for release.
>
> The release artifacts can be found at this location:
>        https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.0/
>
> The source distribution is provided by:
>        apache-tinkerpop-3.6.0-src.zip
>
> Two binary distributions are provided for user convenience:
>        apache-tinkerpop-gremlin-console-3.6.0-bin.zip
>        apache-tinkerpop-gremlin-server-3.6.0-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>        https://tinkerpop.apache.org/docs/3.6.0/ (user docs)
>        https://tinkerpop.apache.org/docs/3.6.0/upgrade/ (upgrade docs)
>        https://tinkerpop.apache.org/javadocs/3.6.0/core/ (core javadoc)
>        https://tinkerpop.apache.org/javadocs/3.6.0/full/ (full javadoc)
>        https://tinkerpop.apache.org/dotnetdocs/3.6.0/ (.NET API docs)
>        https://tinkerpop.apache.org/jsdocs/3.6.0/ (Javascript API docs)
>
> The Git tag can be found here:
>        https://github.com/apache/tinkerpop/tree/3.6.0
>
> The release notes are available here:
>        https://github.com/apache/tinkerpop/blob/3.6.0/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (April 8,
> 2022) at 5pm ET.
>
> My vote is +1.
>


-- 
*Lyndon Bauto*
Team Lead
Bit Quill Technologies Inc.
lynd...@bitquilltech.com
https://www.bitquilltech.com
  

Re: [VOTE] TinkerPop 3.5.3 Release

[Kelvin Lawrence]

VOTE +1
Kelvin
On Tuesday, April 5, 2022, 04:50:41 PM CDT, Lyndon Bauto 
 wrote:  
 
 VOTE+1

On Tue, Apr 5, 2022 at 10:05 AM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.5.3 is ready for release.
>
> The release artifacts can be found at this location:
>        https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.3/
>
> The source distribution is provided by:
>        apache-tinkerpop-3.5.3-src.zip
>
> Two binary distributions are provided for user convenience:
>        apache-tinkerpop-gremlin-console-3.5.3-bin.zip
>        apache-tinkerpop-gremlin-server-3.5.3-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>        https://tinkerpop.apache.org/docs/3.5.3/ (user docs)
>        https://tinkerpop.apache.org/docs/3.5.3/upgrade/ (upgrade docs)
>        https://tinkerpop.apache.org/javadocs/3.5.3/core/ (core javadoc)
>        https://tinkerpop.apache.org/javadocs/3.5.3/full/ (full javadoc)
>        https://tinkerpop.apache.org/dotnetdocs/3.5.3/ (.NET API docs)
>        https://tinkerpop.apache.org/jsdocs/3.5.3/ (Javascript API docs)
>
> The Git tag can be found here:
>        https://github.com/apache/tinkerpop/tree/3.5.3
>
> The release notes are available here:
>        https://github.com/apache/tinkerpop/blob/3.5.3/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (April 8,
> 2022) at 1pm ET.
>
> My vote is +1.
>


-- 
*Lyndon Bauto*
Team Lead
Bit Quill Technologies Inc.
lynd...@bitquilltech.com
https://www.bitquilltech.com
  

Re: [DISCUSS] Create an element() step that maps a Property to its Element.

[Kelvin Lawrence]

This makes sense I think.  Will it be that common for such a service to return 
properties rather than the vertex containing the properties? I suppose you are 
thinking of a case where I do not know the key name and just search on values?

Kelvin On Thursday, February 24, 2022, 08:55:12 AM CST, Mike Personick 
 wrote:  
 
 I would like to add an ElementStep and corresponding .element() operator.

There is currently no way to traverse from a Property to its Element in
Gremlin.

Example use case for this would be service calls that return properties
(e.g. full-text search), which could then be traversed to their owning
element. I am sure there are others.

I will assume a lazy consensus and proceed with this change if there are no
objections in the next 72 hours.

Here is the JIRA:
https://issues.apache.org/jira/browse/TINKERPOP-2713

Thanks,
MIke
  

RE: Re: [Discuss] Design discussion for complex PRs

[Kelvin Lawrence]

I am definitely sympathetic to having solid designs for major features, but
I am also a little allergic to heavyweight processes that hinder speed of
execution. I have seen other projects, at Apache and elsewhere, that fail
to get any features added due to the incredible number of differing
opinions around key feature design. I am not in favor of having the PMC
need to approve all new feature work. That will just turn away future new
contributors. We want to embrace people willing to help us innovate. I
would assert we should be able to achieve consensus on new features via the
Dev list (here). I would suggest we let the new proposal process run for a
while and refine it as necessary.

Cheers,
Kelvin

On 2022/02/11 10:29:16 Stephen Mallette wrote:
> We have a mechanism for "proposals" described here:
>
>
https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/index.asciidoc#proposals
>
> Norio Akagi submitted the first one with the "Equality, Equivalence,
> Comparability and Orderability Semantics" document. My suggestion would be
> to refine that further if needed and see a few more proposals land in
there
> before engineering in too much process. In the longer run, I dont believe
> "proposals" should require PMC involvement or require specific VOTE
> threads. TinkerPop tends to build consensus on design decisions easily
here
> and should continue to take advantage of that.
>
> Divij (and others if interested), you might also look at the Cassandra
> community with their Cassandra Enhancement Proposals (CEP):
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>
>
>
>
>
>
>
>
>
> On Thu, Feb 10, 2022 at 5:04 PM Divij Vaidya 
> wrote:
>
> > Hey folks
> >
> > We have recently had some big PR contributions (such as Go Client,
Gremln
> > language semantics) which are complex enough to require a technical
design
> > review by the community.
> >
> > Currently, as a project, we don't seem to have a process or mechanism
which
> > suggests that the contributors should provide an accompanying design
doc to
> > their PRs. This leads to churn during the implementation/PR phase.
> >
> > In light of the above, may I suggest the following:
> > 1. Add a section in the "contributing to TinkerPop
> > "
> > page where contributors should be encouraged to submit a design document
> > (via JIRA) for complex changes/new features before their PR could be
> > considered for review.
> > 2. Establish a process for design reviews (similar to other Kafka
projects)
> > where a design should be approved by PMC votes.
> > 3. Each design get's a PMC shepherd who would be intimately familiar
with
> > the design and would be the primary code reviewer.
> >
> > Examples of other Apache projects having a similar process:
> > 1. Kafka's KIP:
> >
> >
https://cwiki.apache.org/confluence/display/kafka/kafka+improvement+proposals
> > 2. Spark's SPIP: https://spark.apache.org/improvement-proposals.html
> >
> > Thoughts?
> >
> > Regards,
> > Divij Vaidya
> >
>

Re: [VOTE] TinkerPop 3.5.2 Release

[Kelvin Lawrence]

VOTE +1

Cheers, Kelvin


> On Jan 11, 2022, at 05:39, Stephen Mallette  wrote:
> 
> Hello,
> 
> We are happy to announce that TinkerPop 3.5.2 is ready for release.
> 
> The release artifacts can be found at this location:
>https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.2/
> 
> The source distribution is provided by:
>apache-tinkerpop-3.5.2-src.zip
> 
> Two binary distributions are provided for user convenience:
>apache-tinkerpop-gremlin-console-3.5.2-bin.zip
>apache-tinkerpop-gremlin-server-3.5.2-bin.zip
> 
> The GPG key used to sign the release artifacts is available at:
>https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> 
> The online docs can be found here:
>https://tinkerpop.apache.org/docs/3.5.2/ (user docs)
>https://tinkerpop.apache.org/docs/3.5.2/upgrade/ (upgrade docs)
>https://tinkerpop.apache.org/javadocs/3.5.2/core/ (core javadoc)
>https://tinkerpop.apache.org/javadocs/3.5.2/full/ (full javadoc)
>https://tinkerpop.apache.org/dotnetdocs/3.5.2/ (.NET API docs)
>https://tinkerpop.apache.org/jsdocs/3.5.2/ (Javascript API docs)
> 
> The tag in Apache Git can be found here:
>https://github.com/apache/tinkerpop/tree/3.5.2
> 
> The release notes are available here:
>https://github.com/apache/tinkerpop/blob/3.5.2/CHANGELOG.asciidoc
> 
> The [VOTE] will be open for the next 72 hours --- closing Friday (January
> 14, 2022) at 6:30am ET.
> 
> My vote is +1.

Re: [DISCUSS] Remove docs from zip distributions

[Kelvin Lawrence]

If the docs for each release are available elsewhere it would seem reasonable 
to me to remove them from the Gremlin Server zip file to cut down the size of 
the releases which will be a nice win for people making forks of the tree.
CheersKelvin
On Monday, January 10, 2022, 10:17:46 AM CST, Stephen Mallette 
 wrote:  
 
 As I was working through the release, I noticed that the bulk of our 170Mb
(which zips to 80Mb) of Gremlin Server zip distribution 50Mb is the docs
and 94Mb is the javadoc. We have revisited this question in a while so I
pose it here - is there value to including one or both of those or should
we remove them to lighten the load?
  

Re: [DISCUSS] consider 3.4.13/3.5.2/3.6.0 release

[Kelvin Lawrence]

The work for adding a regex TextP is sitting on the TINKERPOP-2652 branch. I 
still need to write the docs and add one last Java test but otherwise it's 
close to PR ready. I would like to try and get that into 3.6 which I think I 
should be able to do before the cutoff.
In general capturing what we have now into a set of releases makes sense to 
start the year with a pretty clean mainline branch that we can iterate on.
Kelvin

On Monday, December 13, 2021, 06:44:46 AM CST, Stephen Mallette 
 wrote:  
 
 I'd like to propose we do a release for the new year, with code freeze
starting conveniently on Friday December 31.

I think we should also consider making this the last release of 3.4.x.

It occurred to me that 3.6.x doesn't have a name yet. Working in reverse
(never done it this way before), I have a Victorian/Steampunk sorta Gremlin
image that could be used for a logo, and searching around for related music
came across a whole genre of Steampunk Music. First artist group I clicked
on, Deus Ex Vapore Machina, has a song called "Tinkerheart" - sorta just
fits I'd say.
  

[jira] [Created] (TINKERPOP-2652) Add TextP.regex to the text predicate set

[Kelvin Lawrence (Jira)]

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

[Kelvin Lawrence (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

RE: [VOTE] TinkerPop 3.4.12 Release

[Kelvin Lawrence]

VOTE +!

Cheers,
Kelvin


From: Joshua Shinavier
Sent: Thursday, July 22, 2021 1:10 PM
To: dev@tinkerpop.apache.org
Subject: Re: [VOTE] TinkerPop 3.4.12 Release

+1


On Thu, Jul 22, 2021 at 11:06 AM David Bechberger 
wrote:

> +1
>
> On Tue, Jul 20, 2021 at 11:02 AM Stephen Mallette 
> wrote:
>
> > Docs look good and validate-distribution.sh passed
> >
> > VOTE +1
> >
> > On Tue, Jul 20, 2021 at 5:01 AM Florian Hockmann  >
> > wrote:
> >
> > > Hello,
> > >
> > > We are happy to announce that TinkerPop 3.4.12 is ready for release.
> > >
> > > The release artifacts can be found at this location:
> > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.12/
> > >
> > > The source distribution is provided by:
> > > apache-tinkerpop-3.4.12-src.zip
> > >
> > > Two binary distributions are provided for user convenience:
> > > apache-tinkerpop-gremlin-console-3.4.12-bin.zip
> > > apache-tinkerpop-gremlin-server-3.4.12-bin.zip
> > >
> > > The GPG key used to sign the release artifacts is available at:
> > > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> > >
> > > The online docs can be found here:
> > > https://tinkerpop.apache.org/docs/3.4.12/ (user docs)
> > > https://tinkerpop.apache.org/docs/3.4.12/upgrade/ (upgrade
> docs)
> > > https://tinkerpop.apache.org/javadocs/3.4.12/core/ (core
> > javadoc)
> > > https://tinkerpop.apache.org/javadocs/3.4.12/full/ (full
> > javadoc)
> > > https://tinkerpop.apache.org/dotnetdocs/3.4.12/ (.NET API
> docs)
> > > https://tinkerpop.apache.org/jsdocs/3.4.12/ (Javascript API
> > docs)
> > >
> > > The tag in Apache Git can be found here:
> > > https://github.com/apache/tinkerpop/tree/3.4.12
> > >
> > > The release notes are available here:
> > >
> > https://github.com/apache/tinkerpop/blob/3.4.12/CHANGELOG.asciidoc
> > >
> > > The [VOTE] will be open for the next 72 hours --- closing Friday (July
> > 23,
> > > 2021) at 10am UTC.
> > >
> > > My vote is +1.
> > >
> > > Thank you very much,
> > > Florian Hockmann
> > >
> > >
> >
>

Re: [DISCUSS] datetime

[Kelvin Lawrence]

A big +1 from me for this. As much as possible making Gremlin a language that 
does not depend on closures for things like dates and string manipulation will 
help with parity when compared to other query languages.
Kelvin


On Wednesday, July 21, 2021, 07:49:17 AM CDT, Stephen Mallette 
 wrote:  
 
 One of the things precluding a move toward a more pure usage of
gremlin-language in place of groovy scripts is a way to instantiate a
date/time. It seems simple enough to just include a datetime() function in
the grammar that will parse a ISO-8601 formatted dates:

datetime('2021-07-21')
datetime('2021-07-21T01:12:59')
datetime('2021-07-21T01:12:59+0500')

Each language can retain its own method for producing datetime that it
already has.
  

Re: [VOTE] TinkerPop 3.5.1 Release

[Kelvin Lawrence]

Thanks for all the hard work to get the release out. VOTE +1
Kelvin
On Wednesday, July 21, 2021, 01:00:34 PM CDT, Stephen Mallette 
 wrote:  
 
 It was an unfortunate omission but we probably should have had the gremlint
library in the 3.5.1 upgrade docs. oh well, not something to retrigger all
that work over. Florian, please plan to call attention to it in the release
announcement in some way. I'll write something to add to the upgrade docs
for 3.5.1 so it will be there in the future.

Other than that, bin/valdiate-distribution.sh worked fine so VOTE +1

On Wed, Jul 21, 2021 at 10:16 AM Florian Hockmann 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.5.1 is ready for release.
>
> The release artifacts can be found at this location:
>        https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.1/
>
> The source distribution is provided by:
>        apache-tinkerpop-3.5.1-src.zip
>
> Two binary distributions are provided for user convenience:
>        apache-tinkerpop-gremlin-console-3.5.1-bin.zip
>        apache-tinkerpop-gremlin-server-3.5.1-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
>    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
>        https://tinkerpop.apache.org/docs/3.5.1/ (user docs)
>        https://tinkerpop.apache.org/docs/3.5.1/upgrade/ (upgrade docs)
>        https://tinkerpop.apache.org/javadocs/3.5.1/core/ (core javadoc)
>        https://tinkerpop.apache.org/javadocs/3.5.1/full/ (full javadoc)
>        https://tinkerpop.apache.org/dotnetdocs/3.5.1/ (.NET API docs)
>        https://tinkerpop.apache.org/jsdocs/3.5.1/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
>        https://github.com/apache/tinkerpop/tree/3.5.1
>
> The release notes are available here:
>        https://github.com/apache/tinkerpop/blob/3.5.1/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Saturday (July
> 24,
> 2021) at 3pm UTC.
>
> My vote is +1.
>
> Thank you very much,
> Florian Hockmann
>
>
  

Re: [DISCUSS] go driver

[Kelvin Lawrence]

I would agree with considering Go as the next official GLV. In my conversations 
with Gremlin users, Go is by far the language I get asked about the most in 
terms of languages that we currently do not have a GLV for.
Cheers,Kelvin
On Thursday, July 15, 2021, 09:37:44 AM CDT, Joshua Shinavier 
 wrote:  
 
 +1 to official support for Go. In terms of popularity, it seems most often
to land in the top 10 than the top 5 in developer lists, but anecdotally,
it is increasingly used in companies that take after Google. My company has
two officially supported languages, FWIW: Go (#1) and Java (#2).

Josh


On Wed, Jul 14, 2021 at 1:05 PM Stephen Mallette 
wrote:

> If there were a candidate for another official Gremlin driver, I'd say that
> it would have to be Go. I've heard more requests for official support there
> than anything else. As far as I know there are no less than five different
> third-party Go drivers out there right now which further leads me to
> believe that folks want this functionality.
>
> I do have concerns about the additional overhead of yet another programming
> language to support, but if it helps unify a programming language space
> where we have a large number of users who would benefit, it's probably
> worth considering.
>
> Happy to hear from anyone with thoughts about adding support for Go,
> experience with any of the third-party Go drivers out there, etc.
>
  

Re: [VOTE] TinkerPop 3.5.0 Release

[Kelvin Lawrence]

VOTE +1

Cheers, Kelvin

> On May 5, 2021, at 15:49, Stephen Mallette  wrote:
> 
> Hello,
> 
> We are happy to announce that TinkerPop 3.5.0 is ready for release.
> 
> The release artifacts can be found at this location:
>https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.0/
> 
> The source distribution is provided by:
>apache-tinkerpop-3.5.0-src.zip
> 
> Two binary distributions are provided for user convenience:
>apache-tinkerpop-gremlin-console-3.5.0-bin.zip
>apache-tinkerpop-gremlin-server-3.5.0-bin.zip
> 
> The GPG key used to sign the release artifacts is available at:
>https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> 
> The online docs can be found here:
>https://tinkerpop.apache.org/docs/3.5.0/ (user docs)
>https://tinkerpop.apache.org/docs/3.5.0/upgrade/ (upgrade docs)
>https://tinkerpop.apache.org/javadocs/3.5.0/core/ (core javadoc)
>https://tinkerpop.apache.org/javadocs/3.5.0/full/ (full javadoc)
>https://tinkerpop.apache.org/dotnetdocs/3.5.0/ (.NET API docs)
>https://tinkerpop.apache.org/jsdocs/3.5.0/ (Javascript API docs)
> 
> The tag in Apache Git can be found here:
>https://github.com/apache/tinkerpop/tree/3.5.0
> 
> The release notes are available here:
>https://github.com/apache/tinkerpop/blob/3.5.0/CHANGELOG.asciidoc
> 
> The [VOTE] will be open for the next 72 hours --- closing Saturday (May 8,
> 2021) at 5pm ET.
> 
> My vote is +1.

Re: 3.5.0 Announcement Volunteers

[Kelvin Lawrence]

I am happy to help. The area I have been closest too is probably the 
enhancements to the Python client. I could write something around those 
features.

Cheers, Kelvin

> On Apr 30, 2021, at 04:30, f...@florian-hockmann.de wrote:
> 
> I could write something for .NET. Added GraphBinary support and switching 
> the JSON library could be interesting for some Gremlin.Net users.
> 
> -Ursprüngliche Nachricht-
> Von: Stephen Mallette  
> Gesendet: Donnerstag, 29. April 2021 21:32
> An: dev@tinkerpop.apache.org
> Betreff: Re: 3.5.0 Announcement Volunteers
> 
> Right now, I think it's fine for these to just have each person's individual 
> style - might make the posts more interesting assuming we get a few more 
> volunteers. If you can come up with a neat image that could go with a tweet 
> to promote the announcement (that we will push through the TinkerPop 
> account), that would be cool. We've not really come up with anything that 
> sort of iconifies the gremlin-language module, so if you feel like thinking 
> about that, that would be neat.
> 
> 
> 
>> On Thu, Apr 29, 2021 at 2:45 PM Joshua Shinavier  wrote:
>> 
>> Sounds good. I'll write the announcement. If you have thoughts on the 
>> format, please feel free to share.
>> 
>> Josh
>> 
>> On Thu, Apr 29, 2021 at 10:56 AM Stephen Mallette 
>> 
>> wrote:
>> 
>>> On Thu, Apr 29, 2021 at 1:38 PM Joshua Shinavier 
>>> wrote:
>>> 
 I would be happy to collaborate on gremlin-language if there is
>> something
 which needs doing.
 
 Josh
 
 
>>> great josh - thanks! The upgrade docs sorta tuck that feature away 
>>> in the provider section
>>> 
>>> 
>> https://tinkerpop.apache.org/docs/3.5.0-SNAPSHOT/upgrade/#_gremlin_lan
>> guage
>>> 
>>> because at this point it doesn't have direct user impact, but i 
>>> think it might be useful to the community to write something in an 
>>> announcement
>> that
>>> helps describe what this module lays the foundation for. you've had 
>>> some interesting ideas in this area that i'm not sure have gotten 
>>> outside of
>> the
>>> dev list as of yet.
>>> 
>> 
> 

RE: [DSISCUSS] Remote Transactions

[Kelvin Lawrence]

Just a quick comment to add to what others have said. This functionality has 
been a common ask by users who do not want to have to fall back to sending text 
queries just to get the semantics of a session. Thanks for taking this on. It 
will be a nice addition to the Gremlin client/server interaction model. The 
syntax you proposed looks good to me. I assume there will also be an explicit 
rollback ?

Cheers,
Kelvin

Kelvin R. Lawrence
http://www.kelvinlawrence.net
https://www.linkedin.com/in/krlawrence/
Twitter: @gfxman

From: Stephen Mallette
Sent: Thursday, March 18, 2021 7:16 PM
To: dev@tinkerpop.apache.org
Subject: Re: [DSISCUSS] Remote Transactions

I've created this issue for tracking:

https://issues.apache.org/jira/browse/TINKERPOP-2537

and have pushed a branch for early review:

https://github.com/apache/tinkerpop/tree/TINKERPOP-2537

The server-side is a bit of a copy/paste mess at the moment, so try not to
pay attention there too much and focus more on the driver and Transaction
interfaces side of things. At this point I'm amazed at how easily this fell
together. It feels like I'm almost overlooking something important as I'd
not have guessed this to go in so straightforwardly. The hardest part was
figuring out the interaction among the various interfaces to get the user
API right but once that was untangled, stuff just started working.

At this point, I think I need to pay some attention to the server-side
to make this pull request ready. I basically cut/paste a giant grip of code
from TraversalOpProcessor into SessionOpProcessor and tweaked a few lines
here and there. Not terribly ideal, but it was the fastest way to be sure
that the general premise of the client-side was going to actually work. Now
the question is how to make the server part nice, but refactoring there
isn't traditionally easy unfortunately.




On Thu, Mar 18, 2021 at 12:53 PM Stephen Mallette 
wrote:

> First of all, I managed to fumble my last code sample - sorry. You can
> either use the Transaction object explicitly like this:
>
> g = traversal().withRemote(conn)
> tx = g.tx() // Transaction object
> gtx = tx.begin()  // GraphTraversalSource
> assert tx.isOpen() == true
> gtx.addV('person').iterate()
> gtx.addV('software').iterate()
> tx.commit() // alternatively you could explicitly rollback()
> assert tx.isOpen() == false
>
> Or you can look more like the old style:
>
> g = traversal().withRemote(conn)
> gtx = g.tx().begin()  // GraphTraversalSource
> assert gtx.tx().isOpen() == true
> gtx.addV('person').iterate()
> gtx.addV('software').iterate()
> gtx.tx().commit() // alternatively you could explicitly rollback()
> assert gtx.tx().isOpen() == false
>
> Both look fairly fluid I think and I'm especially pleased with the second
> one. Need to do a bit more to prevent weird nested transactions and such
> but pretty neat for a just a day's worth of hacking about.
>
> Answers to Divij's questions inline below:
>
> On Thu, Mar 18, 2021 at 11:52 AM Divij Vaidya 
> wrote:
>
>> Great idea Stephen. I agree with standardizing the explicit transaction
>> semantics in cases of remote server (implicit aka sessionless is already
>> self explanatory) and unifying the syntax with embedded graph usage.
>>
>> Couple of notes:
>>
>> 1. I would favor the begin() instead of create() as it's closer to
>> universally prominent SQL transaction syntax. This would reduce the
>> learning curve for users of TP.
>>
>
> I'm ok with begin().
>
>
>> 2. From an implementation standpoint, sessionless requests are queued on
>> the server side and are serviced by the worker thread pool. But a
>> session-ful aka explicit transaction aka managed transaction starts a new
>> single worked thread pool every time. In a scenario where we have both
>> session-less and sesion-ful requests being made to the server, the
>> resource
>> allocation will not be fair and may lead to starvation for some requests.
>> This problem exists even today, hence not totally correlated to what you
>> are proposing but I am afraid a wider adoption of explicit
>> transactions will bring this problem to the spotlight. Hence, we should
>> fix
>> this problem first. A solution would entail converging the worker pool for
>> both session vs session-less requests.
>>
>> 3. You are proposing the idea of having a transaction scoped traversal
>> object. I agree with it but we need more clarification in behavior wrt the
>> following scenarios:
>>
>> Q. What happens when g.tx().commit() is called on a transaction scoped
>> traversal object? Does the traversal get closed?
>>
>
> If you call gtx.tx().commit() then gtx is dead. If you try do another
> traversal with that it will throw an exception. If you call gtx.close() it
> will close the session and then whatever default handling by the server
> will come into play to commit or rollback. if you call g.tx().commit(),
> meaning on the "parent" to gtx, then you basically send a commit operation
> to the server and that's that.
>
> Q. 

Re: [VOTE] Accepting the gremlint donation

[Kelvin Lawrence]

VOTE +1
Kelvin
Kelvin R. Lawrence  

On Thursday, February 18, 2021, 08:17:41 AM CST, Stephen Mallette 
 wrote:  
 
 whoa! Dylan Millikin! nice to see you back on the list.

On Thu, Feb 18, 2021 at 8:44 AM Dylan Millikin 
wrote:

> Been following this since I would eventually like to get gremlinbin back on
> its feet. Vote +1
>
> On Thu 18 Feb 2021 at 06:58,  wrote:
>
> > VOTE +1
> >
> > -Ursprüngliche Nachricht-
> > Von: Divij Vaidya 
> > Gesendet: Donnerstag, 18. Februar 2021 05:52
> > An: dev@tinkerpop.apache.org
> > Betreff: Re: [VOTE] Accepting the gremlint donation
> >
> > Vote +1
> >
> > On Thu, Feb 18, 2021 at 2:23 AM Stephen Mallette 
> > wrote:
> >
> > > This vote is mostly a formality at this point as we had
> > > consensus[1][2] months ago on accepting the gremlint donation from
> > Øyvind Sæbø and Arqdoc.
> > > The Incubator IP Clearance form has been completed and can be found
> > > here and I will add a link to this thread to it once we are done:
> > >
> > > https://incubator.apache.org/ip-clearance/tinkerpop-gremlint.html
> > >
> > > This VOTE is open for the next 72 hours closing February 20, 2021
> > > 9:00pm ET.
> > >
> > > My VOTE is +1
> > >
> > > [1]
> > >
> > > https://lists.apache.org/thread.html/r5bc915ec5281b3678a62e0be91cb26e7
> > > 089d8a23252b7a5efcac5023%40%3Cdev.tinkerpop.apache.org%3E
> > > [2]
> > >
> > > https://lists.apache.org/thread.html/raaefce2315ce7c32a288faa0657a3981
> > > 9481dc0aff632bdabe0b9b71%40%3Cdev.tinkerpop.apache.org%3E
> > >
> > --
> > Divij Vaidya
> >
> >
>
  

Re: [VOTE] TinkerPop 3.4.10 Release

[Kelvin Lawrence]

VOTE +1
Cheers,Kelvin


On Monday, January 18, 2021, 05:29:43 PM CST, Stephen Mallette 
 wrote:  
 
 Hello,

We are happy to announce that TinkerPop 3.4.10 is ready for release.

The release artifacts can be found at this location:
        https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.10/

The source distribution is provided by:
        apache-tinkerpop-3.4.10-src.zip

Two binary distributions are provided for user convenience:
        apache-tinkerpop-gremlin-console-3.4.10-bin.zip
        apache-tinkerpop-gremlin-server-3.4.10-bin.zip

The GPG key used to sign the release artifacts is available at:
    https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
        https://tinkerpop.apache.org/docs/3.4.10/ (user docs)
        https://tinkerpop.apache.org/docs/3.4.10/upgrade/ (upgrade docs)
        https://tinkerpop.apache.org/javadocs/3.4.10/core/ (core javadoc)
        https://tinkerpop.apache.org/javadocs/3.4.10/full/ (full javadoc)
        https://tinkerpop.apache.org/dotnetdocs/3.4.10/ (.NET API docs)
        https://tinkerpop.apache.org/jsdocs/3.4.10/ (Javascript API docs)

The tag in Apache Git can be found here:
        https://github.com/apache/tinkerpop/tree/3.4.10

The release notes are available here:
        https://github.com/apache/tinkerpop/blob/3.4.10/CHANGELOG.asciidoc

The [VOTE] will be open for the next 72 hours --- closing Thursday (January
21, 2021) at 6:30pm ET.

My vote is +1.

Thank you very much,

Stephen
  

Re: [DISCUSS] consider release of 3.4.10

[Kelvin Lawrence]

Thanks for addressing this so expeditiously Stephen.
I think doing a release to avoid too many users running into this issue and 
having to discover the workaround is a good plan.
CheersKelvin

 

On Thursday, January 14, 2021, 03:22:09 PM CST, Stephen Mallette 
 wrote:  
 
 Hello, Kelvin/Dave B noted this python timeout issue:

https://issues.apache.org/jira/browse/TINKERPOP-2505

It was introduced in 3.4.9 while trying to fix a different problem with
timeouts. Luckily it has a workaround as documented/tested by Kelvin who
wrote this to gremlin-users:

https://groups.google.com/d/msg/gremlin-users/K0EVG3T-UrM/tPf7xz5HCgAJ

As the problem has a simple workaround it is slightly less serious than it
would have been otherwise, but perhaps it would be best to just make the
problem go away with a release. We don't have a lot of changes in 3.4.10
given the last month of development fell during the holiday period, but
there's a few odds and ends in there. I think it's worth doing a release to
remove the need for folks to have to know about the workaround for the
timeouts.

I think we can even avoid a lengthy code freeze in this case as there
aren't many big changes to really test and no big open pull requests that
need to merge. I could start running tests tomorrow and have artifacts up
for VOTE on monday.

If there are no objections in the next 72 hours i'll assume lazy consensus
and proceed in this direction.

Thanks!
  

Re: [DISCUSS] Creating pattern steps to codify best practices

[Kelvin Lawrence]

In general I like the idea of having a simpler way to express an upsert without 
needing to know the coalesce pattern.
I am a little worried that if the addV and addE steps are overloaded to to 
perform the upsert task that suddenly, steps that have always worked one way, 
can now sometimes, do something different - not create but just find an 
existing element. My concern is mainly around readability of queries and a user 
knowing that a step can do certain extra things based on the parameterization. 
This kind of goes a little against the Linux style philosophy of each command 
doing one thing and doing it well.  Again, I'm mostly raising this not because 
I am against the idea but wanting to make sure it is very clear (maybe due to 
the presence of a by() modulator, that a given addV/addE step is in "upsert 
mode". We have a few other cases where steps work differently based on subtle 
parameterizations and people get confused. Consider the case of.
"where(is(eq('A'))"  versus  "where(eq('A'))"
I also want to think a bit about how/if these can be nested. Today a see a lot 
of nested coalesce steps in queries people write trying to do large (complex) 
multi-part upserts.
Cheers,Kelvin
Kelvin R. Lawrence  

On Friday, December 11, 2020, 12:36:45 PM CST, Stephen Mallette 
 wrote:  
 
 +1 to no new step. I haven't yet thought of a reason why this shouldn't
just be a variation on addV/E().

On Fri, Dec 11, 2020 at 1:03 PM David Bechberger 
wrote:

> I agree with Josh's description of what the upsertV() functionality is
> intended to be.
>
> I also fully support the simplification provided by the by() modulation
> that Stephen suggested, removing the second map.  I think that provides a
> much cleaner and easier to comprehend syntax.
>
> With that agreement, I think this does beg the question of if this should
> be a new step (upsertV()) or just an additional signature on the addV()
> step? I
>
> Stephen alluded to this on the dev list and after thinking about this a bit
> I think that I am favor of not adding a step and just adding a new
> signature to the existing step (if possible).  Thoughts?
>
>
> Dave
>
> On Wed, Dec 9, 2020 at 4:33 AM Stephen Mallette 
> wrote:
>
> > Josh, thanks for your thoughts - some responses inline:
> >
> > On Tue, Dec 8, 2020 at 10:16 PM Josh Perryman 
> > wrote:
> >
> > > I'll offer some thoughts. I'm seeing upsertV() as an idempotent
> > getOrCreate
> > > call which always returns a vertex with the label/property values
> > specified
> > > within the step. It's sort of a declarative pattern: "return this
> vertex
> > to
> > > me, find it if you can, create it if you must."
> > >
> >
> > I like this description - I've added it to the gist, though it's a bit at
> > odds with Dave's previous post, so we'll consider it a temporary addition
> > until he responds.
> >
> >
> > > On that account, I do like the simplification in 1. Repetition
> shouldn't
> > be
> > > necessary. In an ideal world, the engine should know the primary
> > > identifiers (name or id) and find/create the vertex based on them. Any
> > > other included values will be "trued up" as well. But this may be a
> > bridge
> > > too far for TinkerPop since knowing identifiers may require a specified
> > > schema. I'd prefer to omit the third input, but it might be necessary
> to
> > > keep it so that the second input can be for the matching use case.
> > >
> >
> > In my most recent post on gremlin-users I think I came up with a nice way
> > to get rid of the second Map. One Map that forms the full list of
> > properties for upserting is easier than partitioning two Maps that
> > essentially merge together. I imagine it's unlikely that application code
> > will have that separation naturally so users will have the added step of
> > trying to separate their data into searchable vs "just data". Getting us
> to
> > one Map argument will simplify APIs for us and reduce complexity to
> users.
> > Here is what I'd proposed for those not following over there:
> >
> > // match on name and age (or perhaps whatever the underlying graph system
> > thinks is best?)
> > g.upsertV('person', [name:'marko',age:29])
> >
> > // match on name only
> > g.upsertV('person', [name:'marko',age:29]).by('name')
> >
> > // explicitly match on name and age
> > g.upsertV('person', [name:'marko',age:29]).
> >  by('name').by('age')
> >
> > // match on id only
> > g.upsertV('person', [(T.id): 100, name:'marko',age:29]).by(T.id)
> >
> > // match on whatever the by(Traversal) predicate defines
> > g.upsertV('person', [name:'marko',age:29]).
> >  by(has('name', 'marko'))
> >
> > // match on id, then update age
> > g.upsertV('person', [(T.id): 100, name:'marko']).by(T.id).
> >  property('age',29)
> >
> > With this model, we get one Map argument that represents the complete
> > property set to be added/updated to the graph and the user can hint on
> what
> > key they wish to match on using by() where that sort of step modulation
> > should be a well 

Re: [New Step Discussion] Add Steps to Support Basic Distribution Analysis (e.g. Standard Deviation and Percentile)

[Kelvin Lawrence]

I quite like the idea of adding some additional reducing barrier steps that 
make it easy to do simple statistical analysis on streams of numbers. Likely 
candidates are `stddev`, `variance` and `product`. It's not easy today to 
calculate the product of a stream in Gremlin using the `math` step. I 
considered suggesting `factorial` also to aid with nPk and nCk type 
calculations but I am not sure about that one.
Cheers,Kelvin
Kelvin R. Lawrence  

On Thursday, December 10, 2020, 11:53:53 PM CST, js guo 
 wrote:  
 
 Thanks for the reply. It is a good idea to provide reducing operations through 
math() step. But from my understanding, we still need different reducing steps 
or at least different seed suppliers and reducing operators in the back-end.

gremlin> g.V().values('age').fold().math(local, "stdev(_)")
==>0.816
gremlin> g.inject([1,2,3]).math(local, "product(_)")
==>6

One of the advantage of a reducing step is that we do not need to hold the 
whole collection of numbers. Take standard deviation calculation for example, 
Kelvin’s solution requires manipulation of number arrays. With a reducing step, 
we can accumulate value sum, square sum and count during the traversal and get 
a final result with sqrt((E(X)^2 - E(X^2)). The latter has a better performance 
together with potentially lower memory requirement.

Maybe for math() step, when passing its scope as global, we can replace it with 
a reducing step internally. The main change is how users write queries with 
little change in underlying implementation. This way, we can align math 
functions into one single step, which I think is the right way to go 
considering that there might be more and more analytical functions to be 
supported. BTW, users still need to remember what steps are supported by 
math(). 

gremlin> g.V().values('age').fold().math(local, “mean(_)”)  // default local 
scope, accepts array
==>30.75
gremlin> g.V().values('age').math(global, “mean(_)”)  // internal execution 
with MeanGlobalStep
==>30.75

A further thinking performance wise. In ReducingBarrierStep implementation, 
“projectTraverser” is used to project current traversal into single value and a 
“BinaryOperator” is used to reduce multiple single-values into one. For number 
manipulation, this process involves a lot of boxing and unboxing, and also 
object creation (e.g. creating MeanNumber for MeanGlobalStep 
https://github.com/apache/tinkerpop/blob/3.4-dev/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/MeanGlobalStep.java#L59).
 

I have wondered if we can optimize the reducing framework for number related 
steps, like store intermediate values (for MeanGlobalStep, it is the “count” 
and value “sum”) as step instance variables, and the reducing operation happens 
directly in traverser projection?

On 2020/12/09 12:24:04, Stephen Mallette  wrote: 
> Thanks for posting. In the math department, I think that these two steps
> are asked for commonly and I think we have reached a point where the things
> folks are doing with Gremlin are requiring steps of greater specificity so
> this conversation is definitely expected. We currently have two sorts of
> steps for operating on numbers: reducing steps like sum() and then math()
> step for expressions. It's interesting what you can accomplish with those
> two steps - note here how Kelvin manages standard deviation without lambdas:
> 
> g.V().hasLabel('airport').
>      values('runways').fold().as('runways').
>      mean(local).as('mean').
>      select('runways').unfold().
>      math('(_-mean)^2').mean().math('sqrt(_)')
> 
> https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#stddevone
> 
> In any case, we can see that there is a fair bit of indirection there to do
> the work of a simple stdev() step. I've often wondered if math() could
> behave both in the way it does now and as a form of reducing step. In that
> way we could quietly add new math functions without forming new steps, as I
> can't help imaging that the addition of stdev() and percentile() will then
> follow with: variance(), covariance(), confidence() and so on.  Kelvin
> recently asked me about mult() for use cases that he sees from time to time.
> 
> As it stands our math expression library exp4j:
> 
> https://www.objecthunter.net/exp4j/
> 
> is good at extensibility but isn't' really formed well out of the box to
> handle reducing operations because its architecture forces you to specify
> the number of arguments it will take up front and those arguments must be
> double:
> 
> https://www.objecthunter.net/exp4j/#Custom_functions
> 
> So, that would be an issue to contend with, but technical issues aside and
> focusing instead on the user angle, would math() that worked as follows be
> a good path?
> 
> gremlin> g.V().values('ages').fold().math(local, "stdev(_)")
> ==>0.816
> gremlin> g.inject([1,2,3]).math(local, "product(_)")
> ==>6
> 
> And then, what distinction would there be between a math() step and first

Re: [DISCUSS] Add functions for casting properties

[Kelvin Lawrence]

The subject of casting does seem to come up fairly often and it does mainly 
seem to come up in cases where a property value type has been "overloaded". 
There is also an argument here for having some (optional) more formal  schema 
that could prevent things like a property called age from having values that 
are sometimes integers and sometimes strings in the same graph instantiation.
The other use case I have seen that supports casting is where all the values 
for a given property were initially created as, say, strings, and later people 
find they need to do true numeric comparisons on those values but are not able 
(for some reason) to run a process over the graph to just fix up all of the 
property values.

Cheers,Kelvin
Kelvin R. Lawrence 



On Monday, December 14, 2020, 09:20:26 AM CST, Stephen Mallette 
 wrote:  
 
 Thanks for leading up another important Gremlin step discussion. Some
initial thoughts inline below:

On Mon, Dec 7, 2020 at 10:16 PM David Bechberger 
wrote:

> One of the recent items I have heard quite a few requests for, and had
> several on and off conversations about, is the ability to cast values
> within a Gremlin traversal.  Due to the schemaless nature of Gremlin it is
> very easy to get into a situation where you have a single property that
> contains different datatypes across elements and it would be very nice to
> be able to create a consistent datatype to allow comparisons.  I'd like to
> throw this proposal out here to see what people think.
>

I agree that type conversion is a consistent problem with Gremlin. Having a
form of casting makes sense to me.


> What if we added a step to handle converting to a defined subset of
> datatypes:
>
> Function Signature:
>
> cast(Enum, string)
>
> Enum - This would be an enum containing the datatypes you can cast to:
> * DT.short
> * DT.int
> * DT.long
> * DT.float
> * DT.double
> * DT.char
> * DT.boolean
> * DT.string
>

I'm a bit concerned with doubling down on Java number representations, but
perhaps we are stuck with that?? I'd love to think of a direction that
somehow makes Gremlin better with numbers and therefore less weird with
variants that don't align well with Java's view of numerics, rather than
even more formally encoding numbers to Java.


> string - The property name to cast
>

I'm not sure that i like this argument because it binds the cast() to an
incoming Element (and maybe Map) type. Any reason to not allow cast() to
work more generally?


> Example usages:
>
> g.V().project('name', 'age').by(cast(DT.String, 'name')).by(cast(DT.int,
> 'age'))
> g.V().order().by(cast(DT.int, 'age'))
> g.V().group().by(cast(DT.int, 'age'))
>

I suppose your reasoning is represented in the examples. You're considering
their use in the by() modulation and thus a succinct syntax as opposed to:

g.V().project('name',
'age').by(values('name').cast(DT.String)).by(values('age').cast(DT.int))

I don't mind that syntax myself all that much, especially since I don't
imagine we'd see this syntax used for every by() in a
project()/group()/etc. I would imagine that it would typically be used for
specific property keys where there were some mixed types. If we only cared
about Elements (and Map) for casting and we went with DT as you suggested
then I would prefer that we introduce a new by(String,DT) for this use
case, thus:

g.V().project('name', 'age').by('name', DT.String).by('age', DT.int)
g.V().order().by('age',DT.int)
g.V().group().by('age',DT.int)

which let's us avoid cast() step all together, but right now I sense cast()
as a step sorta needs to exist though as a general step.


> So what happens if the value cannot be cast to the defined type:
>
> I think that the default behavior in this case should be to throw an error.
>

agreed


> I would like to provide two configuration options (via with)
>
> with(CAST.remove) - in any case where the value cannot be cast the
> traverser would be filtered out
>
> with(CAST.default, -999) - in any case the value cannot be cast the
> specified default value (e.g. -999) would be used.  This would reduce the
> complexity and increase the readability of many queries by no longer
> requiring the use of a coalesce() to handle creation of default values .
> This would also enable customers to handle use cases where data is of
> varying types which cannot be handled by the current coalesce() pattern.
>

I see where you're going but I think I'll reserve further thoughts on this
part until some more discussion comes up on the points i've already made.


>
> Dave
>
  

Re: [DISCUSS] Making Gremlin Python more Pythonic

[Kelvin Lawrence]

I have conflicting opinions on this one that lead me to believe we may need 
both.


The complaint I hear most about Gremlin Python is not that the step names are not 
"Pythonic" - in fact I don't think I have ever had a user say that to me me. 
What I do hear a lot is that people find it difficult (and error prone) that you cannot 
just copy and paste a query from the Gremlin Console into Python.


I suppose there are two classes of users here.


1. Those who use Python to get a job done as it is simple and broadly supported. I would 
put myself in that category. I write a lot of Python but I would never call myself a 
"Pythonista" :-)


2. Those who are doing mainstream development in Python and trying to following 
all of the PEP8 best practices and other in-house coding standards. This class 
of user may indeed appreciate a more Python like syntax.


I have no issue with supporting a more snake case style syntax etc. but I do 
not want to see the current syntax go away really either. I know that 
supporting two of something can be additional work but I do not think we could 
make a hard breaking change here anyway. Too much Gremlin Python is in 
production today.


I think the bigger issue honestly, that I know is the subject of another thread, is that it is too hard to accurately 
migrate "Gremlin Console" syntax to Gremlin Python syntax. Tools that simplify that task I think are a much 
higher ask from users than having a more "Pythonic" syntax. I have had multiple users ask me about that 
conversion and I have lost count of how many users I have had to help convert "as" steps to "as_" 
steps etc.


Cheers,
Kelvin

RE: Re: [DISCUSS] Make TinkerGraph Extendable

[Kelvin Lawrence]

Ah got it. My imagination ran a bit wild there envisioning something bigger 
than just extending classes. Makes sense. So the only real concern I would have 
is when we get bug reports that we ask “did you extend any of the classes?”

On 2020/09/11 10:42:24 Stephen Mallette wrote:
> >  "my query fails on Graph DB XYZ but works on unmodified TinkerGraph"
> 
> I can't remember if that was another concern or not, but note that I may
> not have been clear - the intention isn't to make it so TinkerGraph can
> take extensions by way of plugins but by allowing folks to extend from the
> various Java classes that TinkerGraph exposes (which are all currently
> marked as "final"). So "extensible" really just means class inheritance in
> the classic object-oriented definition. Perhaps that additional context
> answers your other questions.
> 
> On Thu, Sep 10, 2020 at 6:44 PM Kelvin Lawrence 
> wrote:
> 
> > In general if people see a need for an extensible TinkerGraph and want to
> > avoid making forks it seems a reasonable ask. My only slight concern might
> > be that we lose the strong likelihood that when a user says something like
> > "my query fails on Graph DB XYZ but works on unmodified TinkerGraph" that
> > there is an issue with the other implementation has or at least some
> > conscious deviation from the "reference implementation". So we will have to
> > get used to asking "have you applied any extensions?". Other than that, if
> > people have good use cases for wanting to extend TinkerGraph I can't think
> > of other reasons right now to say it is a bad idea.
> >
> > Would the extension mechanism you envisage allow for graph providers to
> > customize TinkerGraph to better mirror their implementation's behavior -
> > without needing to fork it?  In one case I can think of, perhaps a provider
> > does not  support all Gremlin steps yet for some reason but wants to enable
> > easy development and testing using TinkerGraph for their users.  Or would
> > you perhaps see that as violating the API contract that final was used to
> > protect?
> >
> > On 2020/09/10 11:33:07, Stephen Mallette  wrote:
> > > Should TinkerGraph be extendable? This is not a new discussion. Most>
> > > notably, Michael Pollmeier long ago wanted to allow for this to>
> > > experiment with a TinkerGraph fork where he used schemas to drastically>
> > > increase the performance:>
> > >
> > > https://github.com/ShiftLeftSecurity/tinkergraph-gremlin>
> > >
> > > which then was replaced by the quite neat:>
> > >
> > > https://github.com/ShiftLeftSecurity/overflowdb>
> > >
> > > To the best of my knowledge, the argument against making TinkerGraph>
> > > extendable has been that allowing extension of TinkerGraph would create>
> > > situations where we felt we couldn't alter TinkerGraph APIs and
> > behaviors>
> > > as easily as we would like and wanted to maintain the flexibility to
> > change>
> > > what we wanted when we wanted without fear of breaking those extending
> > it.>
> > >
> > > Since those early discussions to come to that reasoning many years ago,>
> > > I've learned that TinkerGraph has a lot of interesting usages that you>
> > > normally wouldn't think of. I've seen/heard it used internally within
> > graph>
> > > systems quite regularly. This might be for testing or functional
> > purposes>
> > > and there are times when being able to extend it would be quite handy
> > where>
> > > a fork of TinkerGraph would be too heavy handed. I've also come to the>
> > > realization that in our current times, TinkerGraph is quite stable in
> > terms>
> > > of API and behavior (the two things we've wanted to protect with
> > "final">
> > > modifiers). There are few changes, the last major one probably relates
> > to>
> > > the introduction of null support in 3.5.0 almost 12 months ago.>
> > >
> > > Given these realizations and another recent request to "remove a final"
> > in>
> > > TinkerGraph, I've started to wonder if the reasons we had many years
> > ago>
> > > still hold and am inclined to think that they do not. Does anyone have>
> > > thoughts on the matter?>
> > >
> > > As an aside, it's interesting that when a project lives long enough,
> > the>
> > > decisions that felt like absolutes begin to feel a bit more mutable.
> > For>
> > > example, for years we thought we'd never maintain Gremlin in other>
> > > languages in our repository, but now we hold many languages here and
> > GLVs>
> > > are highly popular in what they allow. Sorta thought provoking>
> > >
> > Cheers,
> > Kelvin
> >
> >
> >
>



Cheers, Kelvin

Re: [DISCUSS] Make TinkerGraph Extendable

[Kelvin Lawrence]

In general if people see a need for an extensible TinkerGraph and want to avoid making forks it seems a 
reasonable ask. My only slight concern might be that we lose the strong likelihood that when a user says 
something like "my query fails on Graph DB XYZ but works on unmodified TinkerGraph" that there is 
an issue with the other implementation has or at least some conscious deviation from the "reference 
implementation". So we will have to get used to asking "have you applied any extensions?". 
Other than that, if people have good use cases for wanting to extend TinkerGraph I can't think of other 
reasons right now to say it is a bad idea. 


Would the extension mechanism you envisage allow for graph providers to 
customize TinkerGraph to better mirror their implementation's behavior - 
without needing to fork it?  In one case I can think of, perhaps a provider 
does not  support all Gremlin steps yet for some reason but wants to enable 
easy development and testing using TinkerGraph for their users.  Or would you 
perhaps see that as violating the API contract that final was used to protect?


On 2020/09/10 11:33:07, Stephen Mallette  wrote:

Should TinkerGraph be extendable? This is not a new discussion. Most>
notably, Michael Pollmeier long ago wanted to allow for this to>
experiment with a TinkerGraph fork where he used schemas to drastically>
increase the performance:>

https://github.com/ShiftLeftSecurity/tinkergraph-gremlin>

which then was replaced by the quite neat:>

https://github.com/ShiftLeftSecurity/overflowdb>

To the best of my knowledge, the argument against making TinkerGraph>
extendable has been that allowing extension of TinkerGraph would create>
situations where we felt we couldn't alter TinkerGraph APIs and behaviors>
as easily as we would like and wanted to maintain the flexibility to change>
what we wanted when we wanted without fear of breaking those extending it.>

Since those early discussions to come to that reasoning many years ago,>
I've learned that TinkerGraph has a lot of interesting usages that you>
normally wouldn't think of. I've seen/heard it used internally within graph>
systems quite regularly. This might be for testing or functional purposes>
and there are times when being able to extend it would be quite handy where>
a fork of TinkerGraph would be too heavy handed. I've also come to the>
realization that in our current times, TinkerGraph is quite stable in terms>
of API and behavior (the two things we've wanted to protect with "final">
modifiers). There are few changes, the last major one probably relates to>
the introduction of null support in 3.5.0 almost 12 months ago.>

Given these realizations and another recent request to "remove a final" in>
TinkerGraph, I've started to wonder if the reasons we had many years ago>
still hold and am inclined to think that they do not. Does anyone have>
thoughts on the matter?>

As an aside, it's interesting that when a project lives long enough, the>
decisions that felt like absolutes begin to feel a bit more mutable. For>
example, for years we thought we'd never maintain Gremlin in other>
languages in our repository, but now we hold many languages here and GLVs>
are highly popular in what they allow. Sorta thought provoking>
 

Cheers,
Kelvin

Re: [DISCUSS] Accepting gremlint donation

[Kelvin Lawrence]

I really like the idea of having an Apache TinkerPop hosted linter and style guide 
"enforcer". I have spent many wasted hours hand formatting long Gremlin queries people 
have asked me to look at over the years and the latest version of Gremlint makes that so much 
easier. I also really like the idea of extending the tool in the direction of "Gremlin 
converter". I hear from a lot of users that porting from (let's say) Gremlin Console to 
Gremlin Python (and vice-versa) is painful and hard to get right.


Cheers
Kelvin


On 2020/09/10 11:07:46, Stephen Mallette  wrote:

I've had some on and off discussions with the developer of>

https://gremlint.com/>

whose name is Øyvind btw, about the possibility of making gremlint the>
canonical Gremlin code stylizer, and by that I mean, his donating the code>
(and domain name) to the Apache Software Foundation under our project. That>
situation seems possible now and has been offered to the TinkerPop>
Community.>

I like the idea of bringing this code here because I feel our style guide>
in Gremlin Recipes can only suggest convention and I'd much like to see a>
code library managed by our project enforce a proper Gremlin style that can>
be used not only as the neat single HTML page of gremlint.com but also as a>
code library to Gremlin tool builders.>

I also see the opportunity to grow this tool into an online translator to>
get you from one Gremlin dialect to another which is a constant problem for>
users who are working with the tons of code examples in Gremlin Groovy but>
need to get a fast conversion to Python or Javascript. I know I've had that>
problem myself on many occasions. An easy to use translator like this would>
help users realize that Gremlin in Groovy isn't so different from Gremlin>
in any other language and that once you know the subtleties of the>
differences you can easily learn Gremlin from any example in any language.>

I've not given a ton of thought to how gremlint would be brought in, where>
it would go in our source code tree, or how it fits in to>
release/deployment, but all that discussion can come later. I think that>
for right now, we should simply find consensus on whether or not to go down>
this path.>

Are there any thoughts or concerns about accepting this code base and the>
gremlint.com domain?>
 

Cheers,
Kelvin

Re: [DISCUSS] withEmbedded()

[Kelvin Lawrence]

I think this makes good sense and improves the naming consistency.

Cheers,
Kelvin

On 2020/08/29 13:28:12, Stephen Mallette  wrote: 
> In 3.3.5 we introduced a more unified method to construct "g":> 
> 
> gremlin> g = traversal().withGraph(TinkerFactory.createModern())> 
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]> 
> gremlin> g = traversal().withRemote('conf/remote-graph.properties')> 
> ==>graphtraversalsource[emptygraph[empty], standard]> 
> gremlin> g => 
> traversal().withRemote(DriverRemoteConnection.using('localhost',8182))> 
> ==>graphtraversalsource[emptygraph[empty], standard]> 
> 
> https://tinkerpop.apache.org/docs/3.4.8/upgrade/#_anonymoustraversalsource> 
> 
> I think that approach has been really helpful. Of course, this morning I> 
> was thinking that withGraph(Graph) could be better named if we changed it> 
> to withEmbedded(Graph) which would then make it explicit that there are two> 
> modes of operation at play here in TinkerPop when you go to write your> 
> Gremlin with "g".> 
> 
> You can (1) have a "embedded" graph for which you must have a local> 
> instance available or (2) a "remote" graph for which you need a connection.> 
> 
> I was thinking we could deprecate withGraph() for withEmbedded() in 3.4.9> 
> and drop withGraph() in 3.5.0. Anyone have any thoughts on that matter?> 
>  

Cheers,
Kelvin

Kelvin R. Lawrence
Round Rock, Texas, U.S.A.
http://www.kelvinlawrence.net

Re: Apache S2Graph With Gremlin Support

[Kelvin Lawrence]

Really great to see the adoption rate for TinkerPop continuing to grow and 
congrats to the S2Graph folks.

Keep up the good work guys!

Kelvin

On Friday, August 25, 2017 at 6:07:23 PM UTC-5, Stephen Mallette wrote:
>
> I just saw that Apache S2Graph just released 0.2.0-incubating with 
> TinkerPop support:
>
>
> http://s2graph.incubator.apache.org/releases/s2graph-release-0.2.0-incubating.html
>
> Nice to see yet another TinkerPop-enabled Graph.
>
> Stephen
>

Re: New Committer: David Brown

[Kelvin Lawrence]

Congratulations David - I see a lot of folks very excited about the 
prospect of combining Python and Gremlin!

Kelvin

On Wednesday, August 31, 2016 at 10:10:53 AM UTC-5, Stephen Mallette wrote:
>
> The Project Management Committee (PMC) for Apache TinkerPop has asked 
> David Brown to become a committer and we are pleased to announce that he 
> has accepted.
>
> If you're using TinkerPop with Python today, it's likely because of David 
> Brown's work. He was the first person to implement the Gremlin Server 
> protocol for TinkerPop 3.x outside of my initial implementation. He built 
> many other Python related libraries for TinkerPop since then, provided 
> testing during releases and added a good bit of input on Gremlin Server 
> along the way.
>
> Being a committer enables easier contribution to the project since there 
> is no need to work via the patch submission process. This should enable 
> better productivity.
>
>
>

Re: New PMC: Jason Plurad

[Kelvin Lawrence]

Awesome news - congrats Jason and the whole team for the continued success 
of Tinkerpop! (I now have the visual of Jason in a wig stuck in my head) :-)

Kelvin

On Wednesday, August 31, 2016 at 11:30:10 AM UTC-5, Marko A. Rodriguez 
wrote:
>
> Hello,
>
> Jason Plurad of mailing list support, Gremlin Server/Console development, 
> and IBM Graph fame has accepted a position aboard the illustriously 
> enlightened Apache TinkerPop PMC. Jason has been with TinkerPop for over a 
> year and has consistently produced beyond the whims of the moment and as 
> such, is able to help guide the future of The TinkerPop.
>
> With that, welcome Jason to the board — please don’t put your feet up on 
> the table and for god's sake, don’t forget your white wig when attending 
> the exclusive PMC meetings.
>
> http://www.ontrack-media.net/ss8/ss8m4l4image3.jpg
>
> Marko.
>
> http://markorodriguez.com
>
>
>
>