Re: [DISCUSS] hasKey() should throw an error when invoked on Element traverser

[David Bechberger]

Hello Divij,

I added a few comments to the JIRA and agree that the behavior is
inconsistent but have a different proposal.  Let me know what you think?

Dave

On Tue, Feb 22, 2022 at 3:42 AM Divij Vaidya 
wrote:

> Hey folks
>
> I have created a JIRA to modify the behaviour of hasKey() step when invoked
> for traversers of type Element. Please take a look and let me know if I am
> missing anything here wrt semantics of this step. Since it's a breaking
> change, we would want to add it to 3.6.0 only.
>
> JIRA: https://issues.apache.org/jira/browse/TINKERPOP-2710
>
> Regards,
> Divij Vaidya
>

[jira] [Comment Edited] (TINKERPOP-2710) hasKey() should throw an error when invoked on Elements

[Dave Bechberger (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508546#comment-17508546
 ] 

Dave Bechberger edited comment on TINKERPOP-2710 at 3/18/22, 3:21 AM:
--

I am generally against throwing errors when if the intent of the query is able 
to be determined as errors generally lead to a lot more undifferentiated work 
for a consumer to manage.. 

 

Given the query
{code:java}
g.V().hasKey('age').fold(){code}
 

It seems to be that the intent of this query is to find all the vertices with a 
key of `age` which seems equivalent to 
{code:java}
g.V().has('age'){code}
 and return the elements with the key.

 
{code:java}
gremlin> g.V().has('age')
==>v[1]
==>v[2]
==>v[4]
==>v[6]{code}
This would also be a breaking change but would lead to fewer errors being 
thrown and greater consistency among seemingly identical steps.


was (Author: bechbd):
I am generally against throwing errors when if the intent of the query is able 
to be determined as errors generally lead to a lot more undifferentiated work 
for a consumer to manage.. 

 

Given the query

```

g.V().hasKey('age').fold()

```

It seems to be that the intent of this query is to find all the vertices with a 
key of `age` which seems equivalent to `g.V().has('age')` and return the 
elements with the key.

 

```

gremlin> g.V().has('age')
==>v[1]
==>v[2]
==>v[4]
==>v[6]

```

This would also be a breaking change but would lead to fewer errors being 
thrown and greater consistency among seemingly identical steps.

> hasKey() should throw an error when invoked on Elements
> ---
>
> Key: TINKERPOP-2710
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2710
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language, process
>Affects Versions: 3.6.0
>Reporter: Divij Vaidya
>Priority: Major
>
> *Context*
> hasKey() step can be added to the traversal when the traverser is of type 
> Element or when it is of type Property. 
> When step is invoked for traverser of type property, the behaviour is well 
> defined as, "Remove the {{Property}} traverser if it does not match one of 
> the provided keys." Example query: 
> {noformat}
> gremlin> g.V().properties().hasKey('age').value()
> ==>29
> ==>27
> ==>32
> ==>35{noformat}
> When the step is invoked for traverser of type Element, the behaviour of the 
> step is not documented. [Looking at the 
> code|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
>  implementation, it "removes the element traverser if element has a property 
> with key as '~key' and the value of that property matches 'age'". 
> But [this condition is 
> unsatisfiable|https://github.com/apache/tinkerpop/blob/6a0b71b2af79b1b45f1e2db41946fe85529ed32e/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/ElementHelper.java#L84]
>  because Element can never have a property with key "~key". It would always 
> fail at insertion i.e. the output of hasKey() on Element traverser will 
> always be empty.
> *Change proposed*
> Hence, I propose the following change:
> If hasKey() is applied to a traverser of Element type, then it should throw 
> an error. 
> The code change will be made 
> [here|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
>  . We would introduce a change as follows:
> {noformat}
> if (this.key.equals(T.key.getAccessor())) {
> throw new IllegalArgumentException("hasKey() cannot be applied to 
> traverser of type Element")
> }{noformat}
> *Impact of the change*
> Before the change:
> {noformat}
> // the following query always returns empty results  gremlin> 
> g.V().hasKey('age').fold() 
> gremlin> g.V().hasKey('age').fold()
> ==>[]{noformat}
>  
> After the change:
> {noformat}
> // the following query returns an error
> gremlin> g.V().hasKey('age').fold()
> hasKey() cannot be applied to traverser of type Element{noformat}
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (TINKERPOP-2710) hasKey() should throw an error when invoked on Elements

[Dave Bechberger (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508546#comment-17508546
 ] 

Dave Bechberger edited comment on TINKERPOP-2710 at 3/18/22, 3:20 AM:
--

I am generally against throwing errors when if the intent of the query is able 
to be determined as errors generally lead to a lot more undifferentiated work 
for a consumer to manage.. 

 

Given the query

```

g.V().hasKey('age').fold()

```

It seems to be that the intent of this query is to find all the vertices with a 
key of `age` which seems equivalent to `g.V().has('age')` and return the 
elements with the key.

 

```

gremlin> g.V().has('age')
==>v[1]
==>v[2]
==>v[4]
==>v[6]

```

This would also be a breaking change but would lead to fewer errors being 
thrown and greater consistency among seemingly identical steps.


was (Author: bechbd):
I am generally against throwing errors when if the intent of the query is able 
to be determined as errors generally lead to a lot more undifferentiated work 
for a consumer to manage.. 

 

Given the query

```

g.V().hasKey('age').fold()

```

It seems to be that the intent of this query is that an user wants to find all 
the vertices with a key of `age` which seems equivalent to `g.V().has('age')` 
and return the elements with the key.

 

```

gremlin> g.V().has('age')
==>v[1]
==>v[2]
==>v[4]
==>v[6]

```

This would also be a breaking change but would lead to fewer errors being 
thrown and greater consistency among seemingly identical steps.

> hasKey() should throw an error when invoked on Elements
> ---
>
> Key: TINKERPOP-2710
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2710
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language, process
>Affects Versions: 3.6.0
>Reporter: Divij Vaidya
>Priority: Major
>
> *Context*
> hasKey() step can be added to the traversal when the traverser is of type 
> Element or when it is of type Property. 
> When step is invoked for traverser of type property, the behaviour is well 
> defined as, "Remove the {{Property}} traverser if it does not match one of 
> the provided keys." Example query: 
> {noformat}
> gremlin> g.V().properties().hasKey('age').value()
> ==>29
> ==>27
> ==>32
> ==>35{noformat}
> When the step is invoked for traverser of type Element, the behaviour of the 
> step is not documented. [Looking at the 
> code|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
>  implementation, it "removes the element traverser if element has a property 
> with key as '~key' and the value of that property matches 'age'". 
> But [this condition is 
> unsatisfiable|https://github.com/apache/tinkerpop/blob/6a0b71b2af79b1b45f1e2db41946fe85529ed32e/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/ElementHelper.java#L84]
>  because Element can never have a property with key "~key". It would always 
> fail at insertion i.e. the output of hasKey() on Element traverser will 
> always be empty.
> *Change proposed*
> Hence, I propose the following change:
> If hasKey() is applied to a traverser of Element type, then it should throw 
> an error. 
> The code change will be made 
> [here|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
>  . We would introduce a change as follows:
> {noformat}
> if (this.key.equals(T.key.getAccessor())) {
> throw new IllegalArgumentException("hasKey() cannot be applied to 
> traverser of type Element")
> }{noformat}
> *Impact of the change*
> Before the change:
> {noformat}
> // the following query always returns empty results  gremlin> 
> g.V().hasKey('age').fold() 
> gremlin> g.V().hasKey('age').fold()
> ==>[]{noformat}
>  
> After the change:
> {noformat}
> // the following query returns an error
> gremlin> g.V().hasKey('age').fold()
> hasKey() cannot be applied to traverser of type Element{noformat}
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (TINKERPOP-2710) hasKey() should throw an error when invoked on Elements

[Dave Bechberger (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508546#comment-17508546
 ] 

Dave Bechberger commented on TINKERPOP-2710:


I am generally against throwing errors when if the intent of the query is able 
to be determined as errors generally lead to a lot more undifferentiated work 
for a consumer to manage.. 

 

Given the query

```

g.V().hasKey('age').fold()

```

It seems to be that the intent of this query is that an user wants to find all 
the vertices with a key of `age` which seems equivalent to `g.V().has('age')` 
and return the elements with the key.

 

```

gremlin> g.V().has('age')
==>v[1]
==>v[2]
==>v[4]
==>v[6]

```

This would also be a breaking change but would lead to fewer errors being 
thrown and greater consistency among seemingly identical steps.

> hasKey() should throw an error when invoked on Elements
> ---
>
> Key: TINKERPOP-2710
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2710
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language, process
>Affects Versions: 3.6.0
>Reporter: Divij Vaidya
>Priority: Major
>
> *Context*
> hasKey() step can be added to the traversal when the traverser is of type 
> Element or when it is of type Property. 
> When step is invoked for traverser of type property, the behaviour is well 
> defined as, "Remove the {{Property}} traverser if it does not match one of 
> the provided keys." Example query: 
> {noformat}
> gremlin> g.V().properties().hasKey('age').value()
> ==>29
> ==>27
> ==>32
> ==>35{noformat}
> When the step is invoked for traverser of type Element, the behaviour of the 
> step is not documented. [Looking at the 
> code|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
>  implementation, it "removes the element traverser if element has a property 
> with key as '~key' and the value of that property matches 'age'". 
> But [this condition is 
> unsatisfiable|https://github.com/apache/tinkerpop/blob/6a0b71b2af79b1b45f1e2db41946fe85529ed32e/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/ElementHelper.java#L84]
>  because Element can never have a property with key "~key". It would always 
> fail at insertion i.e. the output of hasKey() on Element traverser will 
> always be empty.
> *Change proposed*
> Hence, I propose the following change:
> If hasKey() is applied to a traverser of Element type, then it should throw 
> an error. 
> The code change will be made 
> [here|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
>  . We would introduce a change as follows:
> {noformat}
> if (this.key.equals(T.key.getAccessor())) {
> throw new IllegalArgumentException("hasKey() cannot be applied to 
> traverser of type Element")
> }{noformat}
> *Impact of the change*
> Before the change:
> {noformat}
> // the following query always returns empty results  gremlin> 
> g.V().hasKey('age').fold() 
> gremlin> g.V().hasKey('age').fold()
> ==>[]{noformat}
>  
> After the change:
> {noformat}
> // the following query returns an error
> gremlin> g.V().hasKey('age').fold()
> hasKey() cannot be applied to traverser of type Element{noformat}
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [DISCUSS] TinkerPop Golang Driver (coming soon!)

[Lyndon Bauto]

Hi all,

On the topic of Gremlin-Go, I would like to provide an update as we have
prepared code that is now release ready (once code review on TinkerPop is
complete).

First off, we decided to add an additional milestone (Milestone 4 below,
incrementing the milestones that come after) to the above list. We now have
the following plan:


   - *Milestone 1 - Basic Connectivity with String Traversals*
   - *Milestone 2 - ResultSet and Programmatic Traversals*
   - *Milestone 3 - TinkerPop Build Infrastructure Integration*
   - *NEW: **Milestone 4 - GA Ready*
   - *Milestone 5 - Sessions, Strategies, Translator, Remote Transactions*
   - *Milestone 6 - Advanced Driver Features and Configuration Options*
   - *Milestone 7 - Performance and Documentation*


We have combined the Milestone 3 and 4 into a pull request which is
available here: https://github.com/apache/tinkerpop/pull/1589/files.

After this pull request is merged, I will take the gremlin-go branch and
merge the code into a release branch, from here we can formally release the
Gremlin-Go code, and make it available for users. We have all the Cucumber
tests passing, so that gives high confidence that the driver is stable for
users and the features are working.

We will be beginning Milestone 5 immediately (while prioritizing
incorporating feedback on the pull request).

Finally, since I got no feedback on the previous question about __/T__ so
we have gone with T__ in the gremlin-go driver. If you disagree with this
and would like to raise your opinion, you can comment on our open pull
request for Milestone 3/4.

Thank you to all the people who have been actively reviewing and developing
this!

On Tue, Mar 1, 2022 at 9:52 AM Lyndon Bauto 
wrote:

> Hi all,
>
> I was looking to see if anyone had input on naming of embedded traversals
> in the Gremlin Go Driver. Typically we would have something like:
> g.V().Foo(__.Bar())
>
> Now in Golang we are currently making this look like:
> g.V().Foo(gremlingo.T__.Bar())
>
> We have the following constraints in go:
> 1. We must prefix something from our package with the package name (hence
> the gremlingo prefix).
> 2. We must prefix something with a capital letter to export it (hence the
> T__ instead of __).
>
> If anyone has any ideas to make this look nicer or has alternative ideas
> for this, please suggest them.
>
> On Wed, Feb 16, 2022 at 3:54 PM Lyndon Bauto 
> wrote:
>
>> Hi all,
>>
>> We have now merged the Gremlin Go Milestone 1 code to
>> https://github.com/apache/tinkerpop/tree/gremlin-go and have opened a
>> pull request that contains the code for Milestone 2 (see
>> https://github.com/apache/tinkerpop/pull/1569).
>>
>> With this change, you can now execute programmatic traversals with the
>> code (see the Getting Started section of
>> https://github.com/lyndonb-bq/tinkerpop/tree/gremlin-go-ms2/gremlin-go
>> for more details).
>>
>> We are now working on Milestone 3, and as requested, will be adding a
>> detailed design document to the milestone.
>>
>> If anyone is interested in joining in on the effort or has questions
>> about the driver, please let me know directly, as there are a few others
>> working on it concurrently and we are moving quickly.
>>
>> On Mon, Jan 31, 2022 at 1:01 PM Lyndon Bauto 
>> wrote:
>>
>>> I am happy to report that we have milestone 1 of the Gremlin Go driver
>>> ready!
>>>
>>> Pull request on GitHub which can be reviewed:
>>> https://github.com/apache/tinkerpop/pull/1556
>>>
>>> I would like to thank Yang (https://github.com/xiazcy), Simon (
>>> https://github.com/simonz-bq), and Rithin (https://github.com/L0Lmaker)
>>> for their contributions. Going forward commit history will be properly
>>> preserved, unfortunately it ended up getting mangled for the first
>>> milestone.
>>>
>>> If anyone is interested in joining in on the effort, please let me know
>>> directly, as there are a few others working on it concurrently and will be
>>> moving quickly to Milestone 2.
>>>
>>> On Wed, Jan 19, 2022 at 3:16 AM Jorge Bay Gondra <
>>> jorgebaygon...@gmail.com> wrote:
>>>
 Sounds good! looking forward to it! I hope I can have some free cycles
 to
 help review it.

 On Tue, Jan 18, 2022 at 11:25 PM Lyndon Bauto
  wrote:

 > Hi all,
 >
 > I am working on a Golang driver for TinkerPop. I will be working on
 it on
 > my fork of TinkerPop
 > . I have
 laid out
 > a plan for delivering it below. Each milestone will come to a main
 branch
 > on the TinkerPop repo (branch yet to be made) that can be reviewed by
 > anyone interested. If you would like to join in the development of the
 > driver please let me know so we can make sure we are working on
 separate
 > things as a couple others are already involved.
 >
 > Each milestone will come with a basic README that ought to have
 enough info
 > for someone to try out the current featu

Re: New Committer: Mike Personick

[Divij Vaidya]

Welcome Mike!

Thank you for excellent work so far and looking forward to more exciting
contributions from you.

Divij Vaidya



On Thu, Mar 17, 2022 at 2:40 PM Mike Personick  wrote:

> Thanks Florian! Very happy to be here!
>
> On Thu, Mar 17, 2022 at 4:11 AM Florian Hockmann 
> wrote:
>
> > The Project Management Committee (PMC) for Apache TinkerPop has asked
> Mike
> > Personick to become a committer and we are pleased to announce their
> > acceptance.
> >
> > Mike has issued some pull requests to TinkerPop that improved core
> aspects
> > of Gremlin like the orderability across types and the addition of a
> ternary
> > boolean logic.
> >
> > He also recently provided a pull request that added a new call() step to
> > Gremlin which makes it possible to execute provider specific functions.
> >
> > Welcome, Mike!
> >
> >
>

Re: New Committer: Mike Personick

[Mike Personick]

Thanks Florian! Very happy to be here!

On Thu, Mar 17, 2022 at 4:11 AM Florian Hockmann 
wrote:

> The Project Management Committee (PMC) for Apache TinkerPop has asked Mike
> Personick to become a committer and we are pleased to announce their
> acceptance.
>
> Mike has issued some pull requests to TinkerPop that improved core aspects
> of Gremlin like the orderability across types and the addition of a ternary
> boolean logic.
>
> He also recently provided a pull request that added a new call() step to
> Gremlin which makes it possible to execute provider specific functions.
>
> Welcome, Mike!
>
>

[jira] [Commented] (TINKERPOP-2717) Gremlin.NET : WebSocketConnection does not check for MessageType.Close, causing error InvalidOperationException: "Received data deserialized into null object messag

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508155#comment-17508155
 ] 

ASF GitHub Bot commented on TINKERPOP-2717:
---

FlorianHockmann commented on pull request #1584:
URL: https://github.com/apache/tinkerpop/pull/1584#issuecomment-1070832546


   > will it be possible to back-port this to 3.4.latest drivers as well?
   
   Our current plan is to not release another version of the 3.4 line at the 
moment. 3.5.0 was released in May 2021 already so there should have been enough 
time to update.
   If there's a critical bug in 3.4 that needs to be fixed, then we could 
probably reconsider. But I would not consider this bug here to be critical.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Gremlin.NET : WebSocketConnection does not check for MessageType.Close, 
> causing error InvalidOperationException: "Received data deserialized into 
> null object message. Cannot operate on it."
> -
>
> Key: TINKERPOP-2717
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2717
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.4.13, 3.5.2
>Reporter: Oliver Towers
>Priority: Minor
>
> h2. Issue:
> If the server sends a valid Close websocket message to the client, the client 
> will throw {{InvalidOperationException}} rather than acknowledge/cleanup the 
> connection gracefully.
> See relevant point where exception is thrown. 
> [here|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L123]
> Close messages from the server can be expected when the server is doing a 
> graceful shutdown, and clients would be expected to reconnect.
> h2. Details:
> A Close websocket message being received by ClientWebSocket, 
> [WebSocketReceiveResult.MessageType|https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.websocketreceiveresult.messagetype?view=net-6.0]
>  will return {{MessageType.Close}}. In this case, the message buffer will be 
> zero-bytes, see these 
> [remarks|https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.websocketreceiveresult.count?view=net-6.0#remarks].
> Currently, Gremlin.NET does not check for this message type in 
> [WebSocketConnection.ReceiveMessageAsync|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/WebSocketConnection.cs#L92]
>  and return a zero-length buffer. In 
> [Connection.HandleReceiveAsync|https://github.com/apache/tinkerpop/blob/7835e7a2c3b19a14f196525da844a2e35ba5a105/gremlin-dotnet/src/Gremlin.Net/Driver/Connection.cs#L118],
>  the attempt to deserialize the empty buffer returns `null` and the check 
> fails.
> h2. Potential Fix
> # If `MessageType == Close` Throw a new connection closed exception from 
> {{WebSocketConnection.ReceiveMessageAsync}} which includes 
> {{WebSocketReceiveResult.CloseStatus}} and 
> {{WebSocketReceiveResult.CloseDescription}} in the exception message and as 
> properties.
> # This will be caught in {{Connection.HandleRecieveAsync}} and treated as 
> fatal and will call {{CloseConnectionBecauseOfFailureAsync}} and will handle 
> completing the close handshake, and notifies pending requests on the 
> connection with the closed connection exception.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (TINKERPOP-2719) hasNext is called on TraverserIterator after transaction is committed

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508131#comment-17508131
 ] 

ASF GitHub Bot commented on TINKERPOP-2719:
---

FlorianHockmann commented on pull request #1586:
URL: https://github.com/apache/tinkerpop/pull/1586#issuecomment-1070783044


   > Please include a CHANGELOG
   
   done


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> hasNext is called on TraverserIterator after transaction is committed
> -
>
> Key: TINKERPOP-2719
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2719
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.2
>Reporter: Florian G
>Priority: Major
>
> In {{{}TraversalOpProcessor{}}}, the {{hasNext()}} [function is 
> called|https://github.com/apache/tinkerpop/blob/a52887d084053cd420580a0c0a80e745b49ee252/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L428]
>  on a {{TraversalIterator}} object after the transaction [is 
> committed|https://github.com/apache/tinkerpop/blob/a52887d084053cd420580a0c0a80e745b49ee252/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L414].
>  This causes issues if the database tries to further execute the traversal 
> upon the {{hasNext()}} call but has no access to the transaction anymore.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (TINKERPOP-2719) hasNext is called on TraverserIterator after transaction is committed

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508130#comment-17508130
 ] 

ASF GitHub Bot commented on TINKERPOP-2719:
---

FlorianHockmann commented on a change in pull request #1586:
URL: https://github.com/apache/tinkerpop/pull/1586#discussion_r828987815



##
File path: 
gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java
##
@@ -383,9 +383,14 @@ protected void handleIterator(final Context context, final 
Iterator itty, final
 break;
 }
 
+// track whether there is anything left in the iterator 
because it needs to be accessed after
+// the transaction could be closed - in that case a call 
to hasNext() could open a new transaction
+// unintentionally
+final boolean moreInIterator = itty.hasNext();

Review comment:
   `hasMore` is only set to `false` in line 401 and that is in the `else` 
block of the if condition: `if (moreInIterator)`. So if we also use `hasMore` 
here instead, then `hasMore` cannot become `false` any more.
   This additional `itty.hasNext()` is needed here to check whether more 
elements are available after the last `next()`. This is also explained in the 
comment above starting at line 337:
   
   ```
   // there is a need to check hasNext() on the iterator because if 
the channel is not writeable the
   // previous pass through the while loop will have next()'d the 
iterator and if it is "done" then a
   // NoSuchElementException will raise its head. also need a check 
to ensure that this iteration doesn't
   // require a forced flush which can be forced by sub-classes.
   ```
   
   This is also in line with the implementation in `AbstractOpProcessor` where 
it's implemented exactly like this. We really just copied the logic from there.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tinkerpop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> hasNext is called on TraverserIterator after transaction is committed
> -
>
> Key: TINKERPOP-2719
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2719
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.2
>Reporter: Florian G
>Priority: Major
>
> In {{{}TraversalOpProcessor{}}}, the {{hasNext()}} [function is 
> called|https://github.com/apache/tinkerpop/blob/a52887d084053cd420580a0c0a80e745b49ee252/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L428]
>  on a {{TraversalIterator}} object after the transaction [is 
> committed|https://github.com/apache/tinkerpop/blob/a52887d084053cd420580a0c0a80e745b49ee252/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/op/traversal/TraversalOpProcessor.java#L414].
>  This causes issues if the database tries to further execute the traversal 
> upon the {{hasNext()}} call but has no access to the transaction anymore.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

New Committer: Mike Personick

[Florian Hockmann]

The Project Management Committee (PMC) for Apache TinkerPop has asked Mike
Personick to become a committer and we are pleased to announce their
acceptance.

Mike has issued some pull requests to TinkerPop that improved core aspects
of Gremlin like the orderability across types and the addition of a ternary
boolean logic.

He also recently provided a pull request that added a new call() step to
Gremlin which makes it possible to execute provider specific functions.

Welcome, Mike!

[jira] [Closed] (TINKERPOP-2721) Order by handling null values as filter

[Pavel (Jira)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel closed TINKERPOP-2721.

Resolution: Not A Problem

> Order by handling null values as filter
> ---
>
> Key: TINKERPOP-2721
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2721
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.6.0
>Reporter: Pavel
>Priority: Major
>
> Snippet
> {code}
> public static void main(String[] args) throws Exception {
> final TinkerGraph g = TinkerGraph.open();
> g.traversal()
>  .addV("V")
>  .property("name", "n1")
>  .addV("V")
>  .property("name", "v2")
>  .property("date", Instant.now())
>  .iterate();
> 
> System.out.println(g.traversal().V().order().by(__.id()).valueMap("name").toList());
> 
> System.out.println(g.traversal().V().order().by("date").valueMap("name").toList());
> System.out.println(g.traversal().V()
> .project("name", "date")
> .by("name").by("date")
> .order().by("date").toList());
> System.out.println(g.traversal().V().group().by("date").toList());
> g.close();
> }
> {code}
> 3.5.3-SNAPSHOT
> {code}
> [{id=0, label=V, name=n1}, {id=2, label=V, date=2022-03-16T12:53:19.038763Z, 
> name=v2}]
> [{id=0, label=V, name=n1}, {id=2, label=V, date=2022-03-16T12:53:19.038763Z, 
> name=v2}]
> [{name=n1, date=null}, {name=v2, date=2022-03-16T12:53:19.038763Z}]
> [{null=[v[0]], 2022-03-16T12:53:19.038763Z=[v[2]]}]
> {code}
> 3.6.0-SNAPSHOT
> {code}
> [{id=0, label=V, name=n1}, {id=2, label=V, date=2022-03-16T12:54:25.005772Z, 
> name=v2}]
> [{id=2, label=V, date=2022-03-16T12:54:25.005772Z, name=v2}]
> [{name=n1}, {name=v2, date=2022-03-16T12:54:25.005772Z}]
> [{2022-03-16T12:54:25.005772Z=[v[2]]}]
> {code}
> But SQL does not filter out of null value during order by clause



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (TINKERPOP-2721) Order by handling null values as filter

[Pavel (Jira)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508063#comment-17508063
 ] 

Pavel commented on TINKERPOP-2721:
--

Thanks for quick reply


For sql like behavior (by doc suggesting)

{code}
g.traversal().V().order().by(__.coalesce(__.values("date"), 
__.constant(null))).valueMap("name", "date").toList()
-> [{name=[n1]}, {date=[2022-03-17T09:02:53.920678Z], name=[v2]}]
{code}

> Order by handling null values as filter
> ---
>
> Key: TINKERPOP-2721
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2721
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.6.0
>Reporter: Pavel
>Priority: Major
>
> Snippet
> {code}
> public static void main(String[] args) throws Exception {
> final TinkerGraph g = TinkerGraph.open();
> g.traversal()
>  .addV("V")
>  .property("name", "n1")
>  .addV("V")
>  .property("name", "v2")
>  .property("date", Instant.now())
>  .iterate();
> 
> System.out.println(g.traversal().V().order().by(__.id()).valueMap("name").toList());
> 
> System.out.println(g.traversal().V().order().by("date").valueMap("name").toList());
> System.out.println(g.traversal().V()
> .project("name", "date")
> .by("name").by("date")
> .order().by("date").toList());
> System.out.println(g.traversal().V().group().by("date").toList());
> g.close();
> }
> {code}
> 3.5.3-SNAPSHOT
> {code}
> [{id=0, label=V, name=n1}, {id=2, label=V, date=2022-03-16T12:53:19.038763Z, 
> name=v2}]
> [{id=0, label=V, name=n1}, {id=2, label=V, date=2022-03-16T12:53:19.038763Z, 
> name=v2}]
> [{name=n1, date=null}, {name=v2, date=2022-03-16T12:53:19.038763Z}]
> [{null=[v[0]], 2022-03-16T12:53:19.038763Z=[v[2]]}]
> {code}
> 3.6.0-SNAPSHOT
> {code}
> [{id=0, label=V, name=n1}, {id=2, label=V, date=2022-03-16T12:54:25.005772Z, 
> name=v2}]
> [{id=2, label=V, date=2022-03-16T12:54:25.005772Z, name=v2}]
> [{name=n1}, {name=v2, date=2022-03-16T12:54:25.005772Z}]
> [{2022-03-16T12:54:25.005772Z=[v[2]]}]
> {code}
> But SQL does not filter out of null value during order by clause



--
This message was sent by Atlassian Jira
(v8.20.1#820001)