[jira] [Commented] (TINKERPOP-1908) Bump to Groovy 2.4.14

[ASF GitHub Bot (JIRA)]

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

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

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/806
  
VOTE: +1


> Bump to Groovy 2.4.14
> -
>
> Key: TINKERPOP-1908
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1908
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> We were at 2.4.11 prior to this - here's the release notes sets for changes 
> since that version:
> http://groovy-lang.org/changelogs/changelog-2.4.12.html
> http://groovy-lang.org/changelogs/changelog-2.4.13.html
> http://groovy-lang.org/changelogs/changelog-2.4.14.html
> It's mostly bug fixes (with one in 2.4.14 that involves the 
> {{GroovyScriptEngine}} and seems relevantt o our usage)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #806: TINKERPOP-1908 Bump to Groovy 2.4.14

[FlorianHockmann]

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/806
  
VOTE: +1


---

[DISCUSS] 3.2.8/3.3.2 Release Issues

[Stephen Mallette]

In a previous thread we had the idea that we would look to release
3.2.8/3.3.2 around the first week of April which means that we will likely
code freeze in about 10 days to focus on review/test/docs. I think that we
want to see these issues polished up before we release:

https://issues.apache.org/jira/browse/TINKERPOP-1866 (Support g:T for .NET)
https://issues.apache.org/jira/browse/TINKERPOP-1854 (Lambdas in .NET -
already has a PR)
https://issues.apache.org/jira/browse/TINKERPOP-1865 (Run .NET tests on
GraphSON 3.0)
https://issues.apache.org/jira/browse/TINKERPOP-1892 (A few failing tests
in .NET)

Jorge/Florian, hopefully you can help us get to the finish line on those
.NET issues?

The following 3 are all python related around lambdas and i think fixing
one will fix all (i'm still digging into these):

https://issues.apache.org/jira/browse/TINKERPOP-1895
https://issues.apache.org/jira/browse/TINKERPOP-1896
https://issues.apache.org/jira/browse/TINKERPOP-1898

Obviously we would want to close out all current PRs that are open as well.
Committers, we could use some reviews please - there is a glut of them at
this point.

Interestingly there's no problems to solve with the Javascript GLV...I
guess I shouldn't be paranoid :)

Are there any concerns with trying to finish up the items I've posted?
Anyone know of anything else that is crucial for this release?

[jira] [Commented] (TINKERPOP-1909) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.

[Ashwini Singh (JIRA)]

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

Ashwini Singh commented on TINKERPOP-1909:
--

Yes, agree to keep this discussion only for 3.X

 

Extending the object model+ de-serialiser could be a temporary solution that we 
have suggested to some of our clients or provided change ourselves. But, its 
not a scalable solution for long term. So , we would prefer to the Java and 
dotnet(+other drivers) to adhere to the same object model for version 3.X. [We 
can definitely move to new model going forward to TinkerPop4+]. And, to me it 
makes sense to keep all the drivers aligned to same model in the same major 
version. Can we scope this fix only for 3.X client drivers, what do you think? 

  

> Gremlin.Net does not have complete object model as compared to other client 
> drivers and unable to de-serialize properties for vertex/edge graphSON.  
> -
>
> Key: TINKERPOP-1909
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1909
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.3.1
>Reporter: Ashwini Singh
>Priority: Major
>
> Looks like the object model for Gremlin.Net client driver is not as par with 
> Java driver. We cannot deserialize a GraphSON response to tinkerpop object 
> completely. For example, Gremlin.Net object model cannot deserialize 
> properties from a graphSON response object (vertex/edges). Currently, we only 
> deserialize id and label field from a vertex/edge graphSON.
>  
> So, to desterilize the object model, users have to write a custom 
> deserialization code and create the object. The current de-serializers (for 
> vertex/edge) will strip off details like properties.
>  
> I am filing it as a bug but it could fall into improvement as well.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Merge of TINKERPOP-1777

[Jorge Bay Gondra]

Looks good to me, so you have my vote :)

No need to rollback IMO.

On Wed, Mar 7, 2018 at 6:05 PM, Stephen Mallette 
wrote:

> I expected to do a +1 today - personally, i don't think you need go through
> the hassle of rollback for an official vote.
>
> On Wed, Mar 7, 2018 at 11:24 AM, Daniel Kuppitz  wrote:
>
> > Hi everyone,
> >
> > this morning I accidentally merged TINKERPOP-1777
> >  into master/. For some
> > reason, I was pretty sure that I got enough VOTEs, but in fact, it was
> only
> > me who really voted. I guess I mixed up some notification emails and
> merged
> > it a bit too quickly.
> >
> > Please let me know if you have any complaints, I think I can roll it
> back,
> > but personally, I don't think that this merge was too bad.
> >
> > Cheers,
> > Daniel
> >
>

Re: [Discuss] Expose metadata from Gremlin Server to Clients.

[Stephen Mallette]

thanks for creating the issue in jira. i assigned myself to it to help
manage it through the process.

>  For #3, Do we need to take this in this work item as well ?

I believe that we should handle 3a as part of this - 3b is something else
and could be removed from the description for now.

As for the branchI just pushed the TINKERPOP-1919 branch:

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

This was a really fast and easy first stab at this to just prove out the
ideas that included:

1. a change to the server to put the "host" in the status attributes (we'll
see what we ultimately want to return here as part of 3a in JIRA, but i
figured that would work for now). the server changes introduced some
deprecation, but it should be backward compatible
2. a change to the java driver that makes the status attributes available
to the caller on the ResultSet object
3. an initial attempt at returning status attributes over a remote
Traversal - i made it accessible through side-effects. not sure if this
should stay that way. we've talked about having "metadata" on a traversal
before. perhaps it would be best exposed that way more generally as a first
class citizen, but that would entail bigger changes that might better be
reserved for 3.4.0 - not sure just what we do with "remote traversals"
(i.e. item 2 in JIRA) yet.

Definitely happy we're not doing this on 3.2.x. I'm not so sure I even like
it on 3.3.x given what I've done so far. Depending on how things develop,
we might want to push this forward to 3.4.x - i think it could be more
cleanly implemented there without having to worry so hard about deprecation
and other things that are binding our hands a bit. There's no target date
for 3.4.x yet though I would guess some time in the summer.


On Tue, Mar 6, 2018 at 5:11 PM, Ashwini Singh <
ashws...@microsoft.com.invalid> wrote:

> Create a incident: https://issues.apache.org/jira/browse/TINKERPOP-1913
>
> For this, I am fine with that. Lets take this as part of above work item.
>
> For #3, Do we need to take this in this work item as well ?
>
> Can someone setup the branch? And we can take it from there.
>
> Thanks a lot guys,
> Ashwini Singh
>
> Sent from Mail for
> Windows 10
>
> From: Stephen Mallette
> Sent: Tuesday, March 6, 2018 3:53 AM
> To: dev@tinkerpop.apache.org
> Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients.
>
> Your summary looks good to me. I also agree that we can omit 3b from this
> body of work. Going back to an earlier question that you had:
>
> >   Can we spilt the change to support for gremlin request/script first and
> bytecode/traversal separately?
>
> I'm a bit concerned that if we don't at least have the design of the
> bytecode/traversal piece thought through fully we might not get the client
> side changes right to support it. Perhaps we see how things go on
> implementation before making a final decision here, but as of right now, I
> tend to feel like we shouldn't split this up.
>
> To just get started, I think I'd like to get the initial development branch
> setup with Gremlin Server returning some metadata. That part is pretty
> easy. Once that branch is setup, anyone contributing can just submit PRs
> against that or just commit directly to it. Then we can have one PR to
> evaluate through the review process for this feature
>
> I guess there is some question as to what version this body of work should
> go to. I think I'd like to skip adding this to 3.2.8 and target 3.3.2 on
> the tp33 branch. At this point, I think 3.2.x should really just contain
> bug fixes and minor enhancements - I don't think this particular
> enhancement qualifies as "minor".
>
> Ashwini, if all that sounds good, could you please create a JIRA ticket
> that contains a final summary and references this thread?
>
>
>
>
>
> On Mon, Mar 5, 2018 at 2:47 PM, Ashwini Singh <
> ashws...@microsoft.com.invalid> wrote:
>
> >
> > To summarize what we have discussed so far:
> > 1.  For API using GremlinRequest/QueryScript, expose response
> > attribute as part of result. Using an approach to similar to Java client
> > driver (using ResultSet) . [Priority0]
> > -- We rely on the last message for response attributes.
> > 2. For GLV, add response attribute as part of Traversal.
> [Priority
> > 0]
> > --Rely on the last message for attributes.
> > 3. Expose other server details (like server setting).  I would
> > suggest to split this design discussion into two directions:
> > a. Metadata for request execution: Only focuses on
> details
> > related to request execution. Can be achieved through #1 and #2.
> > b. Metadata for Gremlin Server:  Focuses on overall
> > metadata for the server. Could be a separate request and fetch the data
> > once for a connection. Any other 

[jira] [Assigned] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1913:
---

Assignee: stephen mallette

> Expose metadata from Gremlin Server to Clients
> --
>
> Key: TINKERPOP-1913
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1913
> Project: TinkerPop
>  Issue Type: Improvement
>Affects Versions: 3.3.1
>Reporter: Ashwini Singh
>Assignee: stephen mallette
>Priority: Major
>
> To summarize what we have discussed so far:
>  1. For API using GremlinRequest/QueryScript, expose response attribute as 
> part of result. Using an approach to similar to Java client driver (using 
> ResultSet) .       [Priority0]
>                   -- We rely on the last message for response attributes.
>   2. For GLV, add response attribute as part of Traversal. [Priority 0]
>                   --Rely on the last message for attributes.
> 3.  Expose other server details (like server setting).  I would suggest to 
> split this design discussion into two directions:
>               a. Metadata for request execution: Only focuses on details 
> related to request execution. Can be achieved through #1 and #2.
>               b. Metadata for Gremlin Server:  Focuses on overall metadata 
> for the server. Could be a separate request and fetch the data once for a 
> connection. 
>  Targeted drivers: dotnet, Java, python, javascript.
> More details: 
> [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Merge of TINKERPOP-1777

[Stephen Mallette]

I expected to do a +1 today - personally, i don't think you need go through
the hassle of rollback for an official vote.

On Wed, Mar 7, 2018 at 11:24 AM, Daniel Kuppitz  wrote:

> Hi everyone,
>
> this morning I accidentally merged TINKERPOP-1777
>  into master/. For some
> reason, I was pretty sure that I got enough VOTEs, but in fact, it was only
> me who really voted. I guess I mixed up some notification emails and merged
> it a bit too quickly.
>
> Please let me know if you have any complaints, I think I can roll it back,
> but personally, I don't think that this merge was too bad.
>
> Cheers,
> Daniel
>

Merge of TINKERPOP-1777

[Daniel Kuppitz]

Hi everyone,

this morning I accidentally merged TINKERPOP-1777
 into master/. For some
reason, I was pretty sure that I got enough VOTEs, but in fact, it was only
me who really voted. I guess I mixed up some notification emails and merged
it a bit too quickly.

Please let me know if you have any complaints, I think I can roll it back,
but personally, I don't think that this merge was too bad.

Cheers,
Daniel

[jira] [Closed] (TINKERPOP-1522) Order of select() scopes

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1522.
-
   Resolution: Fixed
Fix Version/s: 3.4.0

> Order of select() scopes
> 
>
> Key: TINKERPOP-1522
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1522
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
> Fix For: 3.4.0
>
>
> As it currently stands, side-effects have the highest priority when a key is 
> {{select()}}'ed. I just ran into a problem where this behavior was more than 
> disadvantageous:
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.withSideEffect("a", ["a": 
> "marko"]).inject(1).select("a").select("a") // expected result is "marko", 
> not "[a:marko]"
> ==>[a:marko]
> {code}
> In my use-case the map keys were not predictable, hence it's almost 
> impossible to prevent a key name collision. IMO maps (and paths) should take 
> precedence over side-effects.
> It is still possible to get the nested {{a}} key, but I'm pretty sure that 
> the common Gremlin user won't be able to come up with this query:
> {code}
> gremlin> g.withSideEffect("a", ["a": "marko"]).inject(1).select("a").
>map(unfold().filter(select(keys).is("a")).select(values))
> ==>marko
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1522) Order of select() scopes

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/803


> Order of select() scopes
> 
>
> Key: TINKERPOP-1522
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1522
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> As it currently stands, side-effects have the highest priority when a key is 
> {{select()}}'ed. I just ran into a problem where this behavior was more than 
> disadvantageous:
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.withSideEffect("a", ["a": 
> "marko"]).inject(1).select("a").select("a") // expected result is "marko", 
> not "[a:marko]"
> ==>[a:marko]
> {code}
> In my use-case the map keys were not predictable, hence it's almost 
> impossible to prevent a key name collision. IMO maps (and paths) should take 
> precedence over side-effects.
> It is still possible to get the nested {{a}} key, but I'm pretty sure that 
> the common Gremlin user won't be able to come up with this query:
> {code}
> gremlin> g.withSideEffect("a", ["a": "marko"]).inject(1).select("a").
>map(unfold().filter(select(keys).is("a")).select(values))
> ==>marko
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #803: TINKERPOP-1522 Order of select() scopes

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/803


---

[jira] [Closed] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1777.
-
Resolution: Fixed

> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
> Fix For: 3.4.0
>
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-1777:
--
Fix Version/s: 3.4.0

> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
> Fix For: 3.4.0
>
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/805


> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #805: TINKERPOP-1777 Gremlin .max step returns -21474...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/805


---

[jira] [Commented] (TINKERPOP-1777) Gremlin .max step returns -2147483648 for empty result sets

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/805#discussion_r172874794
  
--- Diff: gremlin-test/features/branch/Union.feature ---
@@ -135,7 +135,6 @@ Feature: Step - union()
   | d[3].l   |
   | d[0].l   |
   | d[1.9].d |
-  | d[0].i   |
--- End diff --

> just so i'm clear, this value is no longer in the output because vadas 
(aka v[2]) has no out edges to sum a weight on...is that right?

Exactly.

It's the same thing as doing just `g.V(2).outE()` - the traverser would 
simply die as there are no outgoing edges. Likewise with 
`outE().values('weight').sum()`, there simply is no sum, hence the traverser 
dies.


> Gremlin .max step returns -2147483648 for empty result sets
> ---
>
> Key: TINKERPOP-1777
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1777
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Sebastian Estevez
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> To reproduce:
> {code}gremlin> g.V().values('test').max()
> ==>-2147483648{code}
> This should probably return an exeption, "cannot take max of nothing"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #805: TINKERPOP-1777 Gremlin .max step returns -21474...

[dkuppitz]

Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/805#discussion_r172874794
  
--- Diff: gremlin-test/features/branch/Union.feature ---
@@ -135,7 +135,6 @@ Feature: Step - union()
   | d[3].l   |
   | d[0].l   |
   | d[1.9].d |
-  | d[0].i   |
--- End diff --

> just so i'm clear, this value is no longer in the output because vadas 
(aka v[2]) has no out edges to sum a weight on...is that right?

Exactly.

It's the same thing as doing just `g.V(2).outE()` - the traverser would 
simply die as there are no outgoing edges. Likewise with 
`outE().values('weight').sum()`, there simply is no sum, hence the traverser 
dies.


---