[jira] [Assigned] (TINKERPOP-1535) Bump to support Giraph 1.2.0.

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1535:
---

Assignee: stephen mallette  (was: Marko A. Rodriguez)

> Bump to support Giraph 1.2.0.
> -
>
> Key: TINKERPOP-1535
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1535
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>




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

[jira] [Commented] (TINKERPOP-1535) Bump to support Giraph 1.2.0.

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1535:
-

Probably should retry this for 3.4.0.

> Bump to support Giraph 1.2.0.
> -
>
> Key: TINKERPOP-1535
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1535
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>




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

[jira] [Assigned] (TINKERPOP-1494) Means of exposing execution information from a result produced by RemoteConnection

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1494:
---

Assignee: stephen mallette

> Means of exposing execution information from a result produced by 
> RemoteConnection
> --
>
> Key: TINKERPOP-1494
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1494
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.2
>Reporter: Andy Tolbert
>Assignee: stephen mallette
>Priority: Major
>
> When using a Graph Traversal that is backed by a {{RemoteConnection}} it 
> would be useful if there was a way to get information about how the traversal 
> was executed in terms of what host was used and perhaps other information 
> that is useful for that particular {{RemoteConnection}} implementation.  For 
> example, if the underlying connection executes retries on query timeouts, 
> it'd be interesting if that and the hosts that were tried were surfaced in 
> some way.



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

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

[Stephen Mallette]

I just came across this:

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

There's some ideas for what the open source Gremlin Server could return
therefor example, perhaps we send back the the host that executed the
script as the metadata for Gremlin Server?

On Wed, Feb 28, 2018 at 5:37 PM, Ashwini Singh <
ashws...@microsoft.com.invalid> wrote:

>
> Completely agree on making the change for other drivers too. The plan from
> our side is to make changes to other drivers as well.  My focus on
> Gremlin.Net was just for an example . Yes, we should make change to
> Gremlin Server to write the metadata for testing.
>
> I agree to adding this to ResultSet and exposing this as part of every
> response for all the drivers and follow the same pattern as JAVA.
>
> On the gremlin GVL part,  I agree we should support this on traversal for
> bytecode as well. For now, we do not have support for bytecode but we are
> actively working on that and need support for metadata there as well.
> Thanks for bringing this up. Just wanted to understand how we track issues
> at tinkerpop, Can we spilt the change to support for gremlin request/script
> first and bytecode/traversal separately? If we prefer to split the change
> in chunks, but completely fine with one change.
>
> Thanks,
> Ashwini Singh
> Software Engineer @ Azure Cosmos DB
>
> -Original Message-
> From: Stephen Mallette 
> Sent: Wednesday, February 28, 2018 9:58 AM
> To: dev@tinkerpop.apache.org
> Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients.
>
> This newly created issue might be related to this in some way:
>
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%
> 2FTINKERPOP-1906=04%7C01%7Cashwsing%40microsoft.com%
> 7C614b32ff7f984c66554808d57ed4d22b%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636554374885412678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=
> w7pyg6JF4KMbPdpBg6t%2F8cE%2BflbnCQQdyMUgc6HDrXw%3D=0
>
> On Wed, Feb 28, 2018 at 11:37 AM, Florian Hockmann  >
> wrote:
>
> > I agree that we also should make this metadata available for
> > traversals since we want to move users away from sending Gremlin
> > scripts as strings and instead use Bytecode based GLVs.
> >
> > Regarding Gremlin.Net: I think that the implementation would be very
> > similar to how it can be implemented in the Java driver as we tried to
> > stay close to the Java driver in general. The only difference is
> > probably that we currently don't have a ResultSet in Gremlin.Net, but
> > that's only because I didn't see much value in adding that. Metadata
> > would of course be a good argument to also implement a ResultSet in
> > Gremlin.Net and then the implementation should be really basically the
> > same as in the Java driver.
> >
> >
> > Am 28.02.2018 um 16:15 schrieb Stephen Mallette:
> > > I'm fine with using the last response message as the carrier for
> > > this metadata on a particular request. I can't really tell if there
> > > is much
> > work
> > > to do on Gremlin Server itself here. It seems like most of the work
> > > must occur on the various drivers (you mention the .NET api, but all
> > > of the drivers would need to support this feature). However, I would
> > > think that
> > we
> > > would want Gremlin Server itself to append in some kind metadata
> > > (maybe query time? something easy) so that we could write tests
> > > for the drivers in TinkerPop itself. There is also the question of
> > > how we would expose this metadata to GLVs which don't see response
> > > messages at all. A traversal might need some metadata itself so that
> > > the user could retrieve the server metadata from that. The
> > > implementation between Java and the
> > GLVs
> > > might be different here as the GLV traversal class is typically
> > > quite lightweight and only used for generating bytecode.
> > >
> > > I'm not so sure I like the  SubmitAsynWithHeaders()  but I don't
> > > think
> > too
> > > much about how the .NET driver works. Is there a reason to not
> > > always return metadata? could it be expensive to do so? If we just
> > > added an
> > extra
> > > method how would remote traversals configure this option? I think we
> > > need another way. Generally speaking, for Java, I think I would like
> > > to see
> > the
> > > metadata available to the ResultSet somehow which would in turn make
> > > it pretty easy to get it on to a Traversal instance once that
> > > facility was made available.but as to how to enable or disable
> > > the return of the metadata, i'm not sure how that should work just
> > > yet - i need to think on that some more.
> > >
> > > For committers who work on GLVs, please take a look at this thread
> > > and offer your thoughts on how this might work in the GLV driver you
> > > tend to have the most knowledge on. Let's see if we can come to one
> > > nice 

[jira] [Assigned] (TINKERPOP-1461) StarGraph has bad detach/attach logic for properties.

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1461:
---

Assignee: stephen mallette

> StarGraph has bad detach/attach logic for properties.
> -
>
> Key: TINKERPOP-1461
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1461
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop, process, structure
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>
> The following traversal breaks with a {{NullPointerException}} on 
> {{SparkGraphComputer}}.
> {code}
> g.V().as("a").properties().select("a").outE().properties("skill").as("b").dedup().select("b").by(__.value()));
> {code}
> I believe it has to do with detachment in {{Path}}-data.



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

[jira] [Assigned] (TINKERPOP-1446) Add a StringFactory for Path which prefixes with type.

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1446:
---

Assignee: stephen mallette

> Add a StringFactory for Path which prefixes with type.
> --
>
> Key: TINKERPOP-1446
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1446
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Trivial
>
> Here are our various {{StringFactory}} looks:
> {code}
> >>> Vertex(10)
> v[10]
> >>> Edge(2,Vertex(1),"knows",Vertex(2))
> e[2][1-knows->2]
> >>> Property("name","marko")
> p[name->marko]
> >>> VertexProperty(7,"name","marko")
> vp[name->marko]
> >>> Path([],[Vertex(1),"hello",3])
> [v[1], 'hello', 3]
> {code}
> NOTE: this is the same string representation for Gremlin-Java as well.
> Given that {{Path}} is a core interface, I believe it should have a 
> toString() like the other structure interfaces. I propose:
> {code}
> path[v[1], 'hello', 3]
> {code}
> This will make it easy to distinguish it from a list as well.



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

[jira] [Closed] (TINKERPOP-1417) Create a Gremlin language subset that is easy to implement on any VM

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1417.
---
Resolution: Won't Do

This is likely more than what we will try to do in TinkerPop 3.x - the concept 
though is sound. Moved it to the 4.x dev doc:

https://github.com/apache/tinkerpop/commit/fb8facfd35adf5cb18fd761d7610e455a9bbfea3

> Create a Gremlin language subset that is easy to implement on any VM
> 
>
> Key: TINKERPOP-1417
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1417
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>Priority: Major
>
> Implementing the Gremlin VM in another language is pretty straightforward. 
> However, its a lot of code.. all these steps implementations. One thing we 
> could do to make it easy for database providers not on the JVM (e.g. ArangoDB 
> and C) is to create "Gremlito" (Gremlin--). This language subset wouldn't 
> support side-effects, sacks, match, etc. Basically, just simple traversal 
> steps and reducing barrier terminals.
> Thus:
> * out, in, both, values, outE, inV, id, label, etc.
> * repeat
> * select, project
> * where, has, limit, range, is, dedup
> * path, simplePath, cyclicPath
> * groupCount, sum, group, count, max, min, etc. (reducing barriers)
> I suspect the steps above make up 90% of user traversals and all are easy to 
> implement.



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

[jira] [Closed] (TINKERPOP-1326) Use KryoShim for serialization in VertexProgramHelper

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1326.
---
Resolution: Won't Do

Talked with Dan on this a bit and he's no more clear on what the intention was 
here than i was - closing

> Use KryoShim for serialization in VertexProgramHelper
> -
>
> Key: TINKERPOP-1326
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1326
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process, structure
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>Priority: Major
>  Labels: breaking
>
> At the next major release, we should swap out the Java serialization work in 
> {{VertexProgramHelper}} and instead, use the {{KryoShim}} work developed by 
> [~dalaro]. This means we need a {{KryoShimService}} in {{gremlin-core}}. I 
> say we remove the {{HadoopPoolsKryoShimService}} and go with a 
> {{GryoPoolKryoShimService}} that then Hadoop-based OLAP engines can use (as 
> well as engines like TinkerGraph).
> This would a a "minor breaking" change as I suspect no provider is that deep 
> into the serialization API of TinkerPop and the change would be a simple 
> "change X to Y" sort of change for them.



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

[jira] [Updated] (TINKERPOP-1339) Make Step.id() generation faster and simpler

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1339:

Fix Version/s: 3.4.0

> Make Step.id() generation faster and simpler
> 
>
> Key: TINKERPOP-1339
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1339
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>  Labels: breaking
> Fix For: 3.4.0
>
>
> There is a class called {{StepPosition}} that is smart about creating unique 
> ids for steps. Unique, deterministic creation of step ids is important. 
> However, what we have now is expensive. When I original did this, I created 
> an string ID scheme where you could find your location in the traversal, by 
> the id "[0:[1:[2:3]]]" (first step of the root traversal is a traversal 
> parent -- the third step of the second traversal). Why I did it like this I 
> don't know why??! ... Instead, I think we can make things both faster and 
> simpler:
> 1. Change {{Step.id()}} to an integer, not a String.
> 2. Step id labeling is simply walking the traversal tree in a deterministic 
> depth first manner and incrementing a {{nextId++}} counter.
> We can do 2 without 1 and it would not be a breaking change.



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

[jira] [Assigned] (TINKERPOP-1339) Make Step.id() generation faster and simpler

[stephen mallette (JIRA)]

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

stephen mallette reassigned TINKERPOP-1339:
---

Assignee: stephen mallette

> Make Step.id() generation faster and simpler
> 
>
> Key: TINKERPOP-1339
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1339
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>  Labels: breaking
> Fix For: 3.4.0
>
>
> There is a class called {{StepPosition}} that is smart about creating unique 
> ids for steps. Unique, deterministic creation of step ids is important. 
> However, what we have now is expensive. When I original did this, I created 
> an string ID scheme where you could find your location in the traversal, by 
> the id "[0:[1:[2:3]]]" (first step of the root traversal is a traversal 
> parent -- the third step of the second traversal). Why I did it like this I 
> don't know why??! ... Instead, I think we can make things both faster and 
> simpler:
> 1. Change {{Step.id()}} to an integer, not a String.
> 2. Step id labeling is simply walking the traversal tree in a deterministic 
> depth first manner and incrementing a {{nextId++}} counter.
> We can do 2 without 1 and it would not be a breaking change.



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

[jira] [Commented] (TINKERPOP-1374) Consider making Tree an interface

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1374:
-

{{Tree}} not extending from {{HashMap}} would be helpful with a number of 
serialization problems we've faced. We really should treat {{Tree}} with more 
respect

> Consider making Tree an interface
> -
>
> Key: TINKERPOP-1374
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1374
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: structure
>Affects Versions: 3.2.0-incubating
>Reporter: stephen mallette
>Priority: Minor
>
> Tree should be an interface and we should have:
> * OrderedTree
> * SimpleTree
> * BlahTree



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

[jira] [Commented] (TINKERPOP-1367) Preserve path history for min() and max()

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1367:
-

i'm not clear on where this one was left. it seems like a workaround was 
available. can we close this?

> Preserve path history for min() and max()
> -
>
> Key: TINKERPOP-1367
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1367
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Jason Plurad
>Priority: Major
>
> Via https://groups.google.com/d/msg/gremlin-users/qZwsvRjw7L4/YyT-s1foBAAJ
> {noformat}
> gremlin> g.V().outE().as('e').values('weight').path()
> ==>[v[1], e[9][1-created->3], 0.4]
> ==>[v[1], e[7][1-knows->2], 0.5]
> ==>[v[1], e[8][1-knows->4], 1.0]
> ==>[v[4], e[10][4-created->5], 1.0]
> ==>[v[4], e[11][4-created->3], 0.4]
> ==>[v[6], e[12][6-created->3], 0.2]
> gremlin> g.V().outE().as('e').values('weight').max().path()
> ==>[1.0]
> {noformat}
> Currently all reducing barriers are treated the same (min, max, mean, etc.). 
> But they are indeed different when it comes to path computations. Some of 
> them could preserve the path history, others could not.
> For max() and min(), we could preserve the path history. In fact, in this 
> respect, max() and min() would NOT be ReducingBarrierSteps, but in fact be 
> some sort of "barrier" FilterStep.



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

[jira] [Closed] (TINKERPOP-1353) Add metrics to the driver

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1353.
---
Resolution: Won't Do

I don't think I want to push metrics down here. None of the other drivers will 
have such a feature, so maybe just best to leave it alone.

> Add metrics to the driver
> -
>
> Key: TINKERPOP-1353
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1353
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
>
> Not sure of what this entails but it would be nice to have some insight into 
> some of the driver runtime operations (e.g. connection pool size, in-flight 
> requests, etc.)



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

[jira] [Updated] (TINKERPOP-1346) Gryo 4.0

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1346:

Description: 
*Reference*

Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
{code}
Assuming {{Long}} Element ids, the math says:
{code:java}
48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 bytes 
[long]) + 4 bytes + (4 bytes + 8 bytes [long])
{code}
We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
{code}
The math says:
{code:java}
36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 8 
bytes [long]
{code}
Similar techniques would apply to {{ReferenceVertexProperty}} and 
{{ReferenceProperty}}.

*StarGraph*

Right now we serialize first the vertex, then its edges, then its properties. 
We should do vertex, properties, edges. Why? If we know that the vertex is to 
be filtered (which is an analysis of its label/id/properties), then we can skip 
over analyzing its edges. Right now, we may do all this work deserializing 
edges only to realize that the GraphFilter says that the vertex is filtered. 
Dah, pointless clock cycles – especially when edge sets can be massive.

{{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a vertex, 
its properties, its incident edges, and their properties. In essence, one "row 
of an adjacency list."

Here are some ideas on how to make the next version of the serialization format 
more efficient.

1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}. This 
is bad because we have to write the class with each id. It would be better if 
the {{StarGraph}} had metadata like {{vertexIdClass}}, 
{{vertexPropertyIdClass}}, and {{edgeIdClass}}. Now for every vertex we are 
serializing three class, but the benefit is that every id class is now known 
and we can use {{kryo.readObject(..., xxxIdClass)}}.

2. Edges and VertexProperties are written out as {{[ edgeLabel[ edge[ id, 
otherVertexId]*]*}} and {{[ propertyKey[ vertexProperty[ 
id,propertyValue]*]*}}, respectively. This ensures we don't write so many 
strings as all edges/vertex properties are grouped by label. However, we do NOT 
do this for edge properties nor vertex property properties. We simply write out 
the {{Map>}} which is 
{{Map>}}. Since we have to choose between 
grouping by edgeId or by propertyKey, we should keep it as it is, but create a 
"meta map" that allows us to represent all property keys in a, e.g., {{int}} 
space. Thus, {{Map>}} where we 
also have a {{Map}} that is serialized with the 
{{StarGraph}}.

StarGraph also has a Long identifer - This makes no sense as then each 
StarGraph in the full Graph will have similar ids! Moreover, what is 
referencing what when the adjacent vertices are just arbitrary long ids?!! We 
should require that StarGraph get provided ids for vertices (and perhaps 
edges)... We ensure no inconsistencies and we save 64-bits.

 

  was:
*Reference*

Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
{code}
Assuming {{Long}} Element ids, the math says:
{code:java}
48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 bytes 
[long]) + 4 bytes + (4 bytes + 8 bytes [long])
{code}
We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
{code}
The math says:
{code:java}
36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 8 
bytes [long]
{code}
Similar techniques would apply to {{ReferenceVertexProperty}} and 
{{ReferenceProperty}}.

*StarGraph*

Right now we serialize first the vertex, then its edges, then its properties. 
We should do vertex, properties, edges. Why? If we know that the vertex is to 
be filtered (which is an analysis of its label/id/properties), then we can skip 
over analyzing its edges. Right now, we may do all this work deserializing 
edges only to realize that the GraphFilter says that the vertex is filtered. 
Dah, pointless clock cycles – especially when edge sets can be massive.


> Gryo 4.0
> 

[jira] [Closed] (TINKERPOP-1122) StarGraph has a Long nextId. That is pointless and a waste of 64-bits.

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1122.
---
Resolution: Duplicate

Closing in favor of TINKERPOP-1346

> StarGraph has a Long nextId. That is pointless and a waste of 64-bits.
> --
>
> Key: TINKERPOP-1122
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1122
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, io, structure
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>  Labels: breaking
>
> {code}
> protected Long nextId = 0l;
> private Long nextId() {
> return this.nextId++;
> }
> {code}
> This makes no sense as then each StarGraph in the full Graph will have 
> similar ids! Moreover, what is referencing what when the adjacent vertices 
> are just arbitrary long ids?!!  We should require that StarGraph get provided 
> ids for vertices (and perhaps edges)... We ensure no inconsistencies and we 
> save 64-bits.



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

[jira] [Closed] (TINKERPOP-1343) A more efficient StarGraph serialization representation.

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1343.
---
Resolution: Duplicate

Closing in favor of TINKERPOP-1346

> A more efficient StarGraph serialization representation.
> 
>
> Key: TINKERPOP-1343
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1343
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>  Labels: breaking
>
> {{StarGraph}} is used by the Hadoop {{GraphComputers}} and represents a 
> vertex, its properties, its incident edges, and their properties. In essence, 
> one "row of an adjacency list."
> Here are some ideas on how to make the next version of the serialization 
> format more efficient.
> 1. For all Element ids, we currently use {{kryo.readClassAndObject(...)}}. 
> This is bad because we have to write the class with each id. It would be 
> better if the {{StarGraph}} had metadata like {{vertexIdClass}}, 
> {{vertexPropertyIdClass}}, and {{edgeIdClass}}. Now for every vertex we are 
> serializing three class, but the benefit is that every id class is now known 
> and we can use {{kryo.readObject(..., xxxIdClass)}}.
> 2. Edges and VertexProperties are written out as {{[ edgeLabel[ edge[ id, 
> otherVertexId]\*]\*}} and {{[ propertyKey[ vertexProperty[ 
> id,propertyValue]\*]\*}}, respectively. This ensures we don't write so many 
> strings as all edges/vertex properties are grouped by label. However, we do 
> NOT do this for edge properties nor vertex property properties. We simply 
> write out the {{Map>}} which is 
> {{Map>}}. Since we have to choose 
> between grouping by edgeId or by propertyKey, we should keep it as it is, but 
> create a "meta map" that allows us to represent all property keys in a, e.g., 
> {{int}} space. Thus, {{Map>}} 
> where we also have a {{Map}} that is serialized 
> with the {{StarGraph}}.
> There are a few other tickets around optimizing {{StarGraph}} here:
> https://issues.apache.org/jira/browse/TINKERPOP-1128 (making {{GraphFilters}} 
> more efficient)
> https://issues.apache.org/jira/browse/TINKERPOP-1122 (pointless bits and 
> {{StarGraph}} should never auto-generate IDs as the ID space is distributed).
> https://issues.apache.org/jira/browse/TINKERPOP-1287 (related to heap usage 
> and clock cycles -- not serialization).



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

[jira] [Updated] (TINKERPOP-1346) Gryo 4.0

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1346:

Description: 
*Reference*

Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
{code}
Assuming {{Long}} Element ids, the math says:
{code:java}
48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 bytes 
[long]) + 4 bytes + (4 bytes + 8 bytes [long])
{code}
We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
{code}
The math says:
{code:java}
36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 8 
bytes [long]
{code}
Similar techniques would apply to {{ReferenceVertexProperty}} and 
{{ReferenceProperty}}.

*StarGraph*

Right now we serialize first the vertex, then its edges, then its properties. 
We should do vertex, properties, edges. Why? If we know that the vertex is to 
be filtered (which is an analysis of its label/id/properties), then we can skip 
over analyzing its edges. Right now, we may do all this work deserializing 
edges only to realize that the GraphFilter says that the vertex is filtered. 
Dah, pointless clock cycles – especially when edge sets can be massive.

  was:
Right now, to send a {{ReferenceEdge}} message, we serialize the form as:

{code}
KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
{code}

Assuming {{Long}} Element ids, the math says:

{code}
48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 bytes 
[long]) + 4 bytes + (4 bytes + 8 bytes [long])
{code}

We could get this smaller by not relying on Kryo's {{FieldSerializer}}.

{code}
KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
{code}

The math says:

{code}
36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 8 
bytes [long]
{code}

Similar techniques would apply to {{ReferenceVertexProperty}} and 
{{ReferenceProperty}}.


> Gryo 4.0
> 
>
> Key: TINKERPOP-1346
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1346
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, structure
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>  Labels: breaking
>
> *Reference*
> Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
> {code:java}
> KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
> {code}
> Assuming {{Long}} Element ids, the math says:
> {code:java}
> 48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 
> bytes [long]) + 4 bytes + (4 bytes + 8 bytes [long])
> {code}
> We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
> {code:java}
> KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
> KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
> {code}
> The math says:
> {code:java}
> 36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 
> 8 bytes [long]
> {code}
> Similar techniques would apply to {{ReferenceVertexProperty}} and 
> {{ReferenceProperty}}.
> *StarGraph*
> Right now we serialize first the vertex, then its edges, then its properties. 
> We should do vertex, properties, edges. Why? If we know that the vertex is to 
> be filtered (which is an analysis of its label/id/properties), then we can 
> skip over analyzing its edges. Right now, we may do all this work 
> deserializing edges only to realize that the GraphFilter says that the vertex 
> is filtered. Dah, pointless clock cycles – especially when edge sets can be 
> massive.



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

[jira] [Closed] (TINKERPOP-1337) Provide an "add jar" endpoint

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1337.
---
Resolution: Won't Do

Closing - we can reopen if there is an argument to do so, but I really don't 
think we should go down that path.

> Provide an "add jar" endpoint
> -
>
> Key: TINKERPOP-1337
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1337
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.0-incubating
>Reporter: Daniel Kuppitz
>Priority: Major
>
> Gremlin Server should provide something (an endpoint?) that allows the user 
> to add new jar files, without the need to restart the server.
> We've talked about it before, but I thought it might be a good idea to have a 
> ticket where we collect some thoughts.
> One particular problem we've talked about is this: What if someone wants to 
> update a previously loaded jar? The initial loading of a new jar file seems 
> to be a smaller problem; unloading a jar file to update it with a newer 
> version seems to be a real problem. I would say we simply shouldn't support 
> that. I've looked into other projects (e.g. Hive) and there're ways to load 
> new jars, but not to unload them later. If you really need to get rid of a 
> previously loaded jar, then you'll have to restart the server / JVM.
> Another problem I see are distributed environments, where you have multiple 
> Gremlin Servers running (none knows about the existence of the others) that 
> are requested in a round-robin fashion. I don't have a good idea on how to 
> handle this problem, but a first step in the right direction may be to allow 
> uploads of jar files to distributed file systems. Perhaps Gremlin Server 
> instances could then monitor the contents of a predefined directory within 
> the DFS.



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

[jira] [Commented] (TINKERPOP-1333) Create a new toy graph with its own serializations and IORegistry.

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1333:
-

I think that we could use the new "kitchen sink" graph for this potentially. 

> Create a new toy graph with its own serializations and IORegistry.
> --
>
> Key: TINKERPOP-1333
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1333
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, test-suite
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>
> I found a problem in the latest SNAPSHOT of TinkerPop 3.2.1-SNAPSHOT that had 
> a bad configuration setting in {{SparkGraphComputer}}. This bug did not show 
> up in our test suite because we don't have a graph that has user defined 
> types. That is, types not already in {{GryoMapper}}. I think we need a new 
> toy graph that has user defined types and its part of the {{ProcessXXXSuite}} 
> so both OLTP and OLAP get hit and we ensure that our IORegistry serialization 
> stuff is all prim and proper.



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

[jira] [Closed] (TINKERPOP-1221) Make sure HadoopPools is intialized in all the right spots of Giraph/Spark.

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1221.
---
Resolution: Won't Do

ha - i don't know what this meant, but i'm sure it made sense when marko wrote 
it.

> Make sure HadoopPools is intialized in all the right spots of Giraph/Spark.
> ---
>
> Key: TINKERPOP-1221
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1221
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>
> ...yea, all the right spots.



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

[jira] [Updated] (TINKERPOP-1346) Gryo 4.0

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1346:

Summary: Gryo 4.0  (was: Create custom ReferenceXXX GryoSerializers)

This ticket was about changing the format of Reference* classes, but it really 
is about stamping out a new version of Gryo which I don't think we'll do for 
3.4.x (i think we need to let the serializers settle after the big changes 
there for 3.3.0). I think that if we look at the Reference* classes, we might 
look at the Detached* classes as well, though as we go deeper into 3.x releases 
the reliance on Detached* becomes less and less I guess. Anyway, I think this 
ticket can be the catch-all for ideas related to Gryo 4.0.

> Gryo 4.0
> 
>
> Key: TINKERPOP-1346
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1346
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, structure
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>  Labels: breaking
>
> Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
> {code}
> Assuming {{Long}} Element ids, the math says:
> {code}
> 48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 
> bytes [long]) + 4 bytes + (4 bytes + 8 bytes [long])
> {code}
> We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
> KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
> {code}
> The math says:
> {code}
> 36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 
> 8 bytes [long]
> {code}
> Similar techniques would apply to {{ReferenceVertexProperty}} and 
> {{ReferenceProperty}}.



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

[jira] [Closed] (TINKERPOP-1182) Custom serializers for "detached" classes

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1182.
---
Resolution: Won't Do

At this point, I don't think we should bother mucking with a Gryo 4.0. I think 
we need a real reason to try to optimize here, so for now i'm going to close 
this.

> Custom serializers for "detached" classes
> -
>
> Key: TINKERPOP-1182
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1182
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.1-incubating
>Reporter: stephen mallette
>Priority: Major
>
> To this point, we've relied on the default kryo {{FieldSerializer}} to handle 
> serialization of "detached" classes.  That was convenient but perhaps not 
> ideal.  We could probably have more efficient serialization of those classes, 
> if we had custom serializers for each.  Unsure if this would be a breaking 
> change or not at this point - it may just mean a "new version" of gryo.



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

[jira] [Commented] (TINKERPOP-1123) Execution time in console output

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1123:
-

We have utility functions to do this currently with `clock()` and get some 
timing information with {{profile()}} on individual traversals. I tend to feel 
like that's enough for what the console tries to be as a tool. 

from an implementation perspective, it's not really clear how to make this 
happen nicely. it's almost best handled as an issue with groovy in some sense. 

anyway, just thought i'd comment on this one to see if there's any interest in 
this idea still.

> Execution time in console output
> 
>
> Key: TINKERPOP-1123
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1123
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.1.0-incubating
>Reporter: Jeremy Hanna
>Priority: Minor
>
> Often I'd like to have the execution time for queries.  It would be nice to 
> have this as a default or at least a startup option in the gremlin shell.



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

[jira] [Commented] (TINKERPOP-1896) gremlin-python lambdas error when working on Maps

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1896:
-

There is something really foul with the {{GremlinJythonScriptEngine}} if I 
write the lambda with "groovy" so that it processes with that engine, then all 
is good. I'd say that using groovy for the lambda would be the current 
workaround. 

> gremlin-python lambdas error when working on Maps
> -
>
> Key: TINKERPOP-1896
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1896
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.1
>Reporter: Branden Moore
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin-python lambdas throw an error on the server when the preceding step 
> produces maps.
> {code}
> Traceback (most recent call last):
>   File "foo.py", line 15, in 
>     print g.V().has('name').match(__.as_('x').label().as_('lbl'), 
> __.as_('x').id().as_('id')).select('lbl', 'id').map(lambda: "lambda x: 
> type(x)").toList()
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 52, in toList
>     return list(iter(self))
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 70, in next
>     return self.__next__()
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 43, in __next__
>     self.traversal_strategies.apply_strategies(self)
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 352, in apply_strategies
>     traversal_strategy.apply(traversal)
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/remote_connection.py",
>  line 143, in apply
>     remote_traversal = self.remote_connection.submit(traversal.bytecode)
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/driver_remote_connection.py",
>  line 54, in submit
>     results = result_set.all().result()
>   File 
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 
> 462, in result
>     return self.__get_result()
>   File 
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 
> 414, in __get_result
>     raise exception_type, self._exception, self._traceback
> gremlin_python.driver.protocol.GremlinServerError: 599: AttributeError: type 
> object 'org.apache.tinkerpop.gremlin.process.traversal.dsl' has no attribute 
> 'as_' in 

[jira] [Updated] (TINKERPOP-1902) Remove URI class usage in java driver

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1902:

Labels: breaking  (was: )

This appears that it might be more intrusive than it appears and causes some 
breaks because of changes to public classes/methods (not that anyone should be 
using those, but still...) 

I also noticed that the URI does kinda get used in the {{Connection}} class 
which grabs the host/port from it when establishing the channel. 

> Remove URI class usage in java driver
> -
>
> Key: TINKERPOP-1902
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1902
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
>
> The driver class makes use of the URI class for no other reason (that I can 
> tell/recall) beyond basic validation. Unfortunately the URI class doesn't 
> parse host names that include underscores very well which can cause problems 
> in docker usage. I think we can safely remove that.



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

[jira] [Commented] (TINKERPOP-1862) TinkerGraph VertexProgram message passing doesn't work properly when using Direction.BOTH

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/801
  
I just pushed the fix for the `ToyGraphInputRdd`:


https://github.com/apache/tinkerpop/commit/a61dd58eea353637d74086426e4258de5927a8d9

If your rebase you'll get that little fix. 


> TinkerGraph VertexProgram message passing doesn't work properly when using 
> Direction.BOTH
> -
>
> Key: TINKERPOP-1862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1862
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process, tinkergraph
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Major
>
> I think the messages are being sent properly in TinkerMessenger, but when I 
> call messenger.receiveMessages(), the vertex is getting messages from the 
> outVertex of their edges regardless of the edge direction. This is due to 
> line 71 of TinkerMessenger (linked below) which calls 
> Edge.vertices(direction).next(), thus getting the first result out of the 
> Vertex iterator. For IN or OUT, this isn't a problem. But for BOTH, following 
> line 124 of TinkerEdge (linked below), the outVertex is always returned 
> first. TinkerMessenger needs to be modified to return the correct vertex (I 
> think it's the one that != this.vertex).
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/computer/TinkerMessenger.java#L71
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerEdge.java#L124



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

[GitHub] tinkerpop issue #801: TINKERPOP-1862 TinkerMessenger proper handling of Dire...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/801
  
I just pushed the fix for the `ToyGraphInputRdd`:


https://github.com/apache/tinkerpop/commit/a61dd58eea353637d74086426e4258de5927a8d9

If your rebase you'll get that little fix. 


---

[jira] [Closed] (TINKERPOP-1859) Complex instance of P not serializing to bytecode properly

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1859.
---
Resolution: Fixed
  Assignee: stephen mallette

This is resolve now because of TINKERPOP-1894 :

{code}
>>> g.V().hasLabel("person").has("age", 
>>> P.not_(P.lte(10).and_(P.not_(P.between(11, 
>>> 20.and_(P.lt(29).or_(P.eq(35.values("name").toList()
[u'vadas', u'peter']
{code}

> Complex instance of P not serializing to bytecode properly
> --
>
> Key: TINKERPOP-1859
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1859
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Not sure what's happening but this traversal does not return any results with 
> gremlin-python:
> {code}
> gremlin> g.V().hasLabel("person").has("age", 
> P.not(P.lte(10).and(P.not(P.between(11, 
> 20.and(P.lt(29).or(P.eq(35.values("name")
> ==>vadas
> ==>peter
> {code}
> When looking at the bytecode the python bytecode is different from the java 
> bytecode. The java bytecode for the predicate is:
> {code}
> {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "and",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": "or",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": "gt",
>   "value": {
>   "@type": "g:Int32",
>   "@value": 10
>   }
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "and",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": 
> "gte",
>   "value": {
>   
> "@type": "g:Int32",
>   
> "@value": 11
>   }
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": 
> "lt",
>   "value": {
>   
> "@type": "g:Int32",
>   
> "@value": 20
>   }
>   }
>   }]
>   }
>   }]
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "or",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": "lt",
>   "value": {
>   "@type": "g:Int32",
>   "@value": 29
>   }
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "eq",
>   "value": {
>   "@type": "g:Int32",
>   "@value": 35
> 

[jira] [Commented] (TINKERPOP-1892) GLV test failures for .NET

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1892:
-

Many of these tests are fixed now - just a few left ignored in 
GherkinTestRunner.

> GLV test failures for .NET
> --
>
> Key: TINKERPOP-1892
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1892
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> There are a number of test failures with the latest updates to the GLV test 
> suite on TINKERPOP-1857. Those tests have been "ignored" in 
> {{GherkinTestRunner}}. I wasn't able to discern a pattern there to make this 
> ticket any more specific. Hopefully once someone digs into this one, a better 
> title can be written or more specific JIRA issues can be produced. 



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

[jira] [Closed] (TINKERPOP-1894) GraphSONMessageSerializerV2d0 fails to deserialize valid P.not()

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1894.
---
Resolution: Fixed
  Assignee: stephen mallette

Fixed this via CTR: 

https://github.com/apache/tinkerpop/commit/2350cbe04b5a4ed3fdca389b8a345017a4bc7d0a

There is still something wrong with the .NET tests though. While Python and 
Javascript work quite well with this, .NET is still not happy

> GraphSONMessageSerializerV2d0 fails to deserialize valid P.not()
> 
>
> Key: TINKERPOP-1894
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1894
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Jorge Bay
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> GraphSONMessageSerializerV2d0 is not able to deserialize a {{g : P}} 
> predicate for not.
> You can use the following test to reproduce it:
> {code:java}
> public class GraphSONMessageSerializerV2d0Test {
> // ...
> @Test
> public void shouldDeserializeNotPredicate() throws Exception {
> final RequestMessage m = 
> SERIALIZER.deserializeRequest("{\"requestId\":{\"@type\":\"g:UUID\",\"@value\":\"0397b9c0-ffab-470e-a6a8-644fc80c01d6\"},\"op\":\"bytecode\",\"processor\":\"traversal\",\"args\":{\"gremlin\":{\"@type\":\"g:Bytecode\",\"@value\":{\"step\":[[\"V\"],[\"hasLabel\",\"person\"],[\"has\",\"age\",{\"@type\":\"g:P\",\"@value\":{\"predicate\":\"not\",\"value\":{\"@type\":\"g:P\",\"@value\":{\"predicate\":\"lte\",\"value\":{\"@type\":\"g:Int32\",\"@value\":10}]]}},\"aliases\":{\"g\":\"gmodern\"}}}");
> assertEquals("bytecode", m.getOp());
> assertNotNull(m.getArgs());
> }
> }
> {code}
> The error message:
> {code}
>   at 
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0.deserializeRequest(GraphSONMessageSerializerV2d0.java:103)
>   at 
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0Test.shouldDeserializeNotPredicate(GraphSONMessageSerializerV2d0Test.java:367)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: 
> Could not deserialize the JSON value as required. Nested exception: 
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not 
> deserialize the JSON value as required. Nested exception: 
> java.lang.IllegalStateException: 
> org.apache.tinkerpop.gremlin.process.traversal.P.not([Ljava.lang.Object;)
>  at [Source: 
> 

[jira] [Closed] (TINKERPOP-1891) Serialization of P.not() for gremlin-javascript

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1891.
---
Resolution: Fixed
  Assignee: stephen mallette

Resolved on TINKERPOP-1894 

> Serialization of P.not() for gremlin-javascript
> ---
>
> Key: TINKERPOP-1891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1891
> Project: TinkerPop
>  Issue Type: Bug
>  Components: javascript
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> There are currently four GLV tests that are currently being ignored in 
> gremlin-javascript as they generate failures on execution:
> https://github.com/apache/tinkerpop/commit/48d459482635dafaf7feef09ffa206357cf4488f
> All of these tests suspiciously all contain a {{P.not()}} so it likely has 
> something to do with that.



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

[jira] [Commented] (TINKERPOP-1897) Provide Docker images of Gremlin Server and Console

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
> Otherwise I could also test deployment with this plugin with some test 
image to a private repo and then write the dev docs.

That would be great if you could test things out in private first since 
that is an option. It would be nice to know that we've worked out all the kinks 
in a throwaway repo before we start putting things out in public.

> It should be enough to do docker login

that's good to know - a few words on that in the dev docs should be 
sufficient so that no one has to go look it up in google.

> Now, doing a mvn deploy and therefore docker push for an image that was 
already pushed shouldn't do anything when the artifacts didn't change that go 
in that image.

if i understand you correctly, you're saying that if you push the image to 
3.3.2-SNAPSHOT and then make changes and push again, the 3.3.2-SNAPSHOT would 
update...is that right? if that is the case, then that behavior seems to match 
the nature of a java "SNAPSHOT" (except that there is no archival of the older 
SNAPSHOT).  Either way though, I don't think we need to pollute the TinkerPop 
dockerhub with SNAPSHOT deployments. I think we should look for ways to disable 
the docker plugin on  `deploy` if it is a SNAPSHOT version. I'm not sure that 
there is a way to do that with maven directly, but I think we can come up with 
a way to have the effect of not sending SNAPSHOT images to dockerhub. 


> Provide Docker images of Gremlin Server and Console
> ---
>
> Key: TINKERPOP-1897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1897
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> TinkerPop should provide Docker images of Gremlin Server and Gremlin Console 
> that are deployed together with each release.
> This originated from the mailing list:
> [https://lists.apache.org/thread.html/744ae19afa9b2fd1984c1e4dddc588e98786d9c21b633aab8bfa@%3Cdev.tinkerpop.apache.org%3E]



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

[GitHub] tinkerpop issue #802: Add docker images for console and server TINKERPOP-189...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
> Otherwise I could also test deployment with this plugin with some test 
image to a private repo and then write the dev docs.

That would be great if you could test things out in private first since 
that is an option. It would be nice to know that we've worked out all the kinks 
in a throwaway repo before we start putting things out in public.

> It should be enough to do docker login

that's good to know - a few words on that in the dev docs should be 
sufficient so that no one has to go look it up in google.

> Now, doing a mvn deploy and therefore docker push for an image that was 
already pushed shouldn't do anything when the artifacts didn't change that go 
in that image.

if i understand you correctly, you're saying that if you push the image to 
3.3.2-SNAPSHOT and then make changes and push again, the 3.3.2-SNAPSHOT would 
update...is that right? if that is the case, then that behavior seems to match 
the nature of a java "SNAPSHOT" (except that there is no archival of the older 
SNAPSHOT).  Either way though, I don't think we need to pollute the TinkerPop 
dockerhub with SNAPSHOT deployments. I think we should look for ways to disable 
the docker plugin on  `deploy` if it is a SNAPSHOT version. I'm not sure that 
there is a way to do that with maven directly, but I think we can come up with 
a way to have the effect of not sending SNAPSHOT images to dockerhub. 


---

[jira] [Commented] (TINKERPOP-1897) Provide Docker images of Gremlin Server and Console

[ASF GitHub Bot (JIRA)]

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

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

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
I just pushed two commits, one removes the log output as you suggested and 
the other one was unfortunately necessary on my system to get all tests running 
with `./docker/build.sh -t -n -i`. It simply increases the timeout for one test 
in `gremlin-driver` as that was failing consistently for me.
As already discussed on the mailing list, I can't build the documentation 
right now, so I can't test if my changes broke anything there.


> So mvn deploy will deploy to where? dockerhub?

My understanding of the `dockerfile-maven-plugin` is that it will simply 
wrap `docker push` for deployment which should default to dockerhub.


>  If so, could you include something in the dev docs on how you configure 
your system to allow for that?

It should be enough to do [`docker 
login`](https://docs.docker.com/engine/reference/commandline/login/) once on 
your system which should ask for the credentials and then store them in the 
config. After that, deployment through maven should just work.

How about we deploy release candidate images once this is merged and then 
write the release docs when we've actually done one successful deployment?
Otherwise I could also test deployment with this plugin with some test 
image to a private repo and then write the dev docs.

> Also, what happens when we do a mvn deploy on a SNAPSHOT? that would be 
bad right? I think we need to prevent such things from happening somehow.

I'm not sure yet about that one yet. It would just result in an image with 
a tag like `3.2.8-SNAPSHOT` which shouldn't be a problem.
The ideal case would probably be that we use unique tags like 
`3.2.8-SNAPSHOT-abcde` and then tag the latest of these SNAPSHOT images 
additionally with `3.2.8-SNAPSHOT`, but just having the `3.2.8-SNAPSHOT` tag 
should also be ok.
Now, doing a `mvn deploy` and therefore `docker push` for an image that was 
already pushed shouldn't do anything when the artifacts didn't change that go 
in that image.

Alternatively, we could also try to disable the deployment phase for this 
plugin for `SNAPSHOT` versions, but I don't know how we could do that with 
Maven.

> what does adding this extra step do to the the overall build time (when 
building docker is enabled, of course)?

I just checked with my Ubuntu VM that has just 4 cores and 6 GB RAM and got 
the following times for `mvn install -pl gremlin-server -DskipTests`:
* Without docker build enabled: 33s
* With docker build enabled and no images present: 2:10 min
* With docker build enabled, but the image already present: 51s

When no images are present locally, then it has to download and extract the 
OpenJDK image which is 82 MB big, that took a big part of that time.


> Provide Docker images of Gremlin Server and Console
> ---
>
> Key: TINKERPOP-1897
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1897
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console, server
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> TinkerPop should provide Docker images of Gremlin Server and Gremlin Console 
> that are deployed together with each release.
> This originated from the mailing list:
> [https://lists.apache.org/thread.html/744ae19afa9b2fd1984c1e4dddc588e98786d9c21b633aab8bfa@%3Cdev.tinkerpop.apache.org%3E]



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

[GitHub] tinkerpop issue #802: Add docker images for console and server TINKERPOP-189...

[FlorianHockmann]

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/802
  
I just pushed two commits, one removes the log output as you suggested and 
the other one was unfortunately necessary on my system to get all tests running 
with `./docker/build.sh -t -n -i`. It simply increases the timeout for one test 
in `gremlin-driver` as that was failing consistently for me.
As already discussed on the mailing list, I can't build the documentation 
right now, so I can't test if my changes broke anything there.


> So mvn deploy will deploy to where? dockerhub?

My understanding of the `dockerfile-maven-plugin` is that it will simply 
wrap `docker push` for deployment which should default to dockerhub.


>  If so, could you include something in the dev docs on how you configure 
your system to allow for that?

It should be enough to do [`docker 
login`](https://docs.docker.com/engine/reference/commandline/login/) once on 
your system which should ask for the credentials and then store them in the 
config. After that, deployment through maven should just work.

How about we deploy release candidate images once this is merged and then 
write the release docs when we've actually done one successful deployment?
Otherwise I could also test deployment with this plugin with some test 
image to a private repo and then write the dev docs.

> Also, what happens when we do a mvn deploy on a SNAPSHOT? that would be 
bad right? I think we need to prevent such things from happening somehow.

I'm not sure yet about that one yet. It would just result in an image with 
a tag like `3.2.8-SNAPSHOT` which shouldn't be a problem.
The ideal case would probably be that we use unique tags like 
`3.2.8-SNAPSHOT-abcde` and then tag the latest of these SNAPSHOT images 
additionally with `3.2.8-SNAPSHOT`, but just having the `3.2.8-SNAPSHOT` tag 
should also be ok.
Now, doing a `mvn deploy` and therefore `docker push` for an image that was 
already pushed shouldn't do anything when the artifacts didn't change that go 
in that image.

Alternatively, we could also try to disable the deployment phase for this 
plugin for `SNAPSHOT` versions, but I don't know how we could do that with 
Maven.

> what does adding this extra step do to the the overall build time (when 
building docker is enabled, of course)?

I just checked with my Ubuntu VM that has just 4 cores and 6 GB RAM and got 
the following times for `mvn install -pl gremlin-server -DskipTests`:
* Without docker build enabled: 33s
* With docker build enabled and no images present: 2:10 min
* With docker build enabled, but the image already present: 51s

When no images are present locally, then it has to download and extract the 
OpenJDK image which is 82 MB big, that took a big part of that time.


---

[jira] [Commented] (TINKERPOP-1804) Has step doesn't consider strategy vertexProperty filters

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1804:
---

This is, what the strategy should do:

*Apply vertex property filter:*
{noformat}
g.V().hasLabel("person").has('location', 'seattle').
  filter(properties().or(hasLabel(neq('location')), hasNot('endTime'))).
  valueMap()
{noformat}

*Reapply has-filters (don't remove the original has-steps as they could be 
relevant for index lookups):*
{noformat}
g.V().hasLabel("person").has('location', 'seattle').
  filter(properties().and(
or(hasLabel(neq('location')), hasNot('endTime')),// user-specified 
vertex property filter
hasLabel('location').hasValue('seattle'))).  // rewritten 
has-step(s)
  valueMap()
{noformat}

*Rewrite valueMap:*
{noformat}
g.V().hasLabel("person").has('location', 'seattle').
  filter(properties().and(or(hasLabel(neq('location')), hasNot('endTime')), 
hasLabel('location').hasValue('seattle'))).
  local(properties().or(hasLabel(neq('location')), 
hasNot('endTime')).group().by(key).by(value))
{noformat}

The rewrite of {{valueMap}} is already done differently in the strategy, so 
this step can be ignored. I just did it to show the correct output without 
using the strategy:

{noformat}
gremlin> g.V().hasLabel("person").has('location', 'seattle').
..1>   filter(properties().and(or(hasLabel(neq('location')), 
hasNot('endTime')), hasLabel('location').hasValue('seattle'))).
..2>   local(properties().or(hasLabel(neq('location')), 
hasNot('endTime')).group().by(key).by(value))
==>[name:[matthias],location:[seattle]]
gremlin>
{noformat}

> Has step doesn't consider strategy vertexProperty filters
> -
>
> Key: TINKERPOP-1804
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1804
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Simone Cattani
>Priority: Major
>
> Has step, when used in a traversal defined with strategies, doesn't consider 
> filters applied on properties by the strategies
> Let's consider the crew example adding an old location for Marko, in Seattle, 
> the current Matthias' location.
> {code}
> graph = TinkerFactory.createTheCrew()
> g = graph.traversal()
> g.V().has('name', 'marko').property('location', 'seattle', 'startTime', 1994, 
> 'endTime', 1997)
> {code}
> Defining a strategy that considers just current location I can correctly 
> obtain the list of current locations
> {code}
> g.withStrategies(SubgraphStrategy.build().vertexProperties(or(hasLabel(neq('location')),hasNot('endTime'))).create()).V().hasLabel("person").valueMap()
> ==>[name:[marko],location:[santa fe]]
> ==>[name:[stephen],location:[purcellville]]
> ==>[name:[matthias],location:[seattle]]
> ==>[name:[daniel],location:[aachen]]
> {code}
> But requiring people (currently) living in Seattle, I obtain Marko, too
> {code}
> g.withStrategies(SubgraphStrategy.build().vertexProperties(or(hasLabel(neq('location')),hasNot('endTime'))).create()).V().hasLabel("person").has('location',
>  'seattle').valueMap()
> ==>[name:[marko],location:[santa fe]]
> ==>[name:[matthias],location:[seattle]]
> {code}



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

[jira] [Created] (TINKERPOP-1907) Fix failing GLV test for withSack() in .NET

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1907:
---

 Summary: Fix failing GLV test for withSack() in .NET
 Key: TINKERPOP-1907
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1907
 Project: TinkerPop
  Issue Type: Bug
  Components: dotnet
Affects Versions: 3.2.7
Reporter: stephen mallette
 Fix For: 3.2.8, 3.3.2


This test is currently failing (and is ignored) for .NET: 
{{g_withSackX1_sumX_VX1X_localXoutXknowsX_barrierXnormSackXX_inXknowsX_barrier_sack:}}

Here is the error it is presenting:

{code}
Xunit.Sdk.ContainsException: Assert.Contains() Failure
Not found: 1
In value:  Object[] [1, 1]
   at Xunit.Assert.Contains[T](T expected, IEnumerable`1 collection, 
IEqualityComparer`1 comparer)
   at Gremlin.Net.IntegrationTest.Gherkin.CommonSteps.AssertResult(String 
characterizedAs, DataTable table) in 
/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/CommonSteps.cs:line
 188
{code}



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

[jira] [Assigned] (TINKERPOP-1901) Enable usage of enums in more steps in Gremlin.Net

[Florian Hockmann (JIRA)]

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

Florian Hockmann reassigned TINKERPOP-1901:
---

 Assignee: Florian Hockmann
Fix Version/s: 3.3.2
   3.2.8

We identified this as something that should be done before TINKERPOP-1854, so 
it should also be done for the next release.

(I also started working on this but got a bit distracted by other issues.)

> Enable usage of enums in more steps in Gremlin.Net
> --
>
> Key: TINKERPOP-1901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1901
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> Java enums can implement interfaces and some Gremlin steps take interfaces as 
> arguments that are implemented by enums like {{T}} or {{P}} in Java. However, 
> C# enums can't have any methods and therefore also not implement interfaces. 
> For this reason, step arguments whose type is one of those interfaces 
> ({{Predicate}}, {{Function}}, ...) currently have the type {{object}} in 
> Gremlin.Net which makes it hard for users to know what kind of values they 
> can use for these arguments.
> This overload of the {{By}} step is a good example for this:
>  * In Gremlin-java:
> {code:java}
> public default  GraphTraversal by(final Traversal traversal, 
> final Comparator comparator)
> {code}
>  * In Gremlin.Net:
> {code}
> public GraphTraversal By (object function, object comparator)
> {code}
> [~jorgebg] [suggested two possible 
> solutions|https://github.com/apache/tinkerpop/pull/792#discussion_r167847541] 
> for this problem:
> {quote} * Use a class for T (not an enum), properties like T.Id could return 
> instances of whatever interface we create for it. Given that java enums 
> functionality is more comprehensive than what C# currently supports, it makes 
> sense to use a class IMO.
>  * Generate the offending traversal methods manually.{quote}



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

[jira] [Commented] (TINKERPOP-1885) Various Gremlin.Net documentation updates

[Florian Hockmann (JIRA)]

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

Florian Hockmann commented on TINKERPOP-1885:
-

{quote}As for a ".NET Gremlin", I think that for now you could just use the 
standard Microsoft .NET logo like this:
{quote}
Good idea, I'll see if I can come up with a good combination of the Gremlin 
running log and the .NET logo.
{quote}Florian Hockmann do you have time soon to get the README in place so 
that we can get this one closed?
{quote}
I want to write the README after addressing the review comments for the Docker 
images PR.

> Various Gremlin.Net documentation updates
> -
>
> Key: TINKERPOP-1885
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1885
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation, dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Priority: Trivial
> Fix For: 3.2.8, 3.3.2
>
>
> We have some parts of the documentation regarding Gremlin.Net that should be 
> updated now that we have a stable release:
>  * Homepage: _Query Languages_ misses a reference to Gremlin.Net
>  * Homepage: _Language Drivers_ section still links to the repository on my 
> private account. It should probably link to the Gremlin.Net section in the 
> reference docs or to a {{README}} (see below).
>  * Reference docs still contain a warning that _Gremlin.Net does not yet have 
> an official release._
>  * Add a {{README}} that explains Gremlin.Net, similar to the documents we 
> have for the Python and Javascript GLVs.
>  * The {{csproj}} file contains a pretty extensive {{summary}} element, but 
> {{summary}} isn't part of the {{csproj}} standard. So it isn't used for 
> anything. It should be merged into the {{description}} element instead.



--
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=16382126#comment-16382126
 ] 

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

Github user robertdale commented on the issue:

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


> 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 issue #803: TINKERPOP-1522 Order of select() scopes

[robertdale]

Github user robertdale commented on the issue:

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


---

[jira] [Commented] (TINKERPOP-1862) TinkerGraph VertexProgram message passing doesn't work properly when using Direction.BOTH

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/801
  
I'm sorry to say that spark integration tests are failing for your added 
tests. Not sure what's wrong. I made an initial fix that solved the first body 
of errors. I updated `ToyGraphInputRDD` to include:

```java
else if 
(configuration.getString(Constants.GREMLIN_HADOOP_INPUT_LOCATION).contains("sink"))
vertices = 
IteratorUtils.list(IteratorUtils.map(TinkerFactory.createKitchenSink().vertices(),
 VertexWritable::new));
```

But the tests still fail with:

```text
[ERROR] 
testMessagePassingOut(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 5.693 s  <<< ERROR!
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Name is null
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runMPTest(GraphComputerTest.java:2741)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingOut(GraphComputerTest.java:2710)
Caused by: java.lang.IllegalStateException: Name is null
Caused by: java.lang.NullPointerException: Name is null

[ERROR] 
testMessagePassingBoth(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 5.397 s  <<< ERROR!
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Name is null
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runMPTest(GraphComputerTest.java:2741)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingBoth(GraphComputerTest.java:2726)
Caused by: java.lang.IllegalStateException: Name is null
Caused by: java.lang.NullPointerException: Name is null

[ERROR] 
testMessagePassingIn(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 5.198 s  <<< ERROR!
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Name is null
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runMPTest(GraphComputerTest.java:2741)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingIn(GraphComputerTest.java:2694)
Caused by: java.lang.IllegalStateException: Name is null
Caused by: java.lang.NullPointerException: Name is null
```

Not sure I know what is causing thatI don't what "Name" is referring to 
here. I was guessing the property you just added to "sink" but it's not the 
same case, so..


> TinkerGraph VertexProgram message passing doesn't work properly when using 
> Direction.BOTH
> -
>
> Key: TINKERPOP-1862
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1862
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process, tinkergraph
>Affects Versions: 3.2.7
>Reporter: Philip Graff
>Priority: Major
>
> I think the messages are being sent properly in TinkerMessenger, but when I 
> call messenger.receiveMessages(), the vertex is getting messages from the 
> outVertex of their edges regardless of the edge direction. This is due to 
> line 71 of TinkerMessenger (linked below) which calls 
> Edge.vertices(direction).next(), thus getting the first result out of the 
> Vertex iterator. For IN or OUT, this isn't a problem. But for BOTH, following 
> line 124 of TinkerEdge (linked below), the outVertex is always returned 
> first. TinkerMessenger needs to be modified to return the correct vertex (I 
> think it's the one that != this.vertex).
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/computer/TinkerMessenger.java#L71
> https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerEdge.java#L124



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

[GitHub] tinkerpop issue #801: TINKERPOP-1862 TinkerMessenger proper handling of Dire...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/801
  
I'm sorry to say that spark integration tests are failing for your added 
tests. Not sure what's wrong. I made an initial fix that solved the first body 
of errors. I updated `ToyGraphInputRDD` to include:

```java
else if 
(configuration.getString(Constants.GREMLIN_HADOOP_INPUT_LOCATION).contains("sink"))
vertices = 
IteratorUtils.list(IteratorUtils.map(TinkerFactory.createKitchenSink().vertices(),
 VertexWritable::new));
```

But the tests still fail with:

```text
[ERROR] 
testMessagePassingOut(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 5.693 s  <<< ERROR!
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Name is null
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runMPTest(GraphComputerTest.java:2741)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingOut(GraphComputerTest.java:2710)
Caused by: java.lang.IllegalStateException: Name is null
Caused by: java.lang.NullPointerException: Name is null

[ERROR] 
testMessagePassingBoth(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 5.397 s  <<< ERROR!
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Name is null
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runMPTest(GraphComputerTest.java:2741)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingBoth(GraphComputerTest.java:2726)
Caused by: java.lang.IllegalStateException: Name is null
Caused by: java.lang.NullPointerException: Name is null

[ERROR] 
testMessagePassingIn(org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest)
  Time elapsed: 5.198 s  <<< ERROR!
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Name is null
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.runMPTest(GraphComputerTest.java:2741)
at 
org.apache.tinkerpop.gremlin.process.computer.GraphComputerTest.testMessagePassingIn(GraphComputerTest.java:2694)
Caused by: java.lang.IllegalStateException: Name is null
Caused by: java.lang.NullPointerException: Name is null
```

Not sure I know what is causing thatI don't what "Name" is referring to 
here. I was guessing the property you just added to "sink" but it's not the 
same case, so..


---

Re: [DISCUSS] Name of 3.4.x

[Jason Plurad]

Boyz II Men - ha, I hadn't considered that angle. I assumed the 4 Seasons
was a Vivaldi reference.

How about David Bowie? The Gremlin Who Sold the World
On Thu, Mar 1, 2018 at 8:06 AM Stephen Mallette 
wrote:

> I'm guessing at the reference for "4 Seasons of Gremlin" - are we talking
> Boyz || Men and "4 Seasons of Loneliness"?
>
> >  Yeah, I'd like to see what Gremlyn Manson would look like!
>
> would he look that much different than our "Nine Inch Nails Gremlin"?
>
>
>
> On Tue, Feb 27, 2018 at 10:58 AM, Robert Dale  wrote:
>
> > Yeah, I'd like to see what Gremlyn Manson would look like!
> >
> > Robert Dale
> >
> > On Tue, Feb 27, 2018 at 10:40 AM, Daniel Kuppitz 
> wrote:
> >
> > > Four Rusted Gremlins (reference
> > > ) :)
> > >
> > > On Tue, Feb 27, 2018 at 7:47 AM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > We need a release name and associated Gremlin logo for the 3.4.x
> series
> > > of
> > > > TinkerPop. Recall that names should be related to music and include a
> > > > number. Thus far we've had:
> > > >
> > > > * Gremlin Symphony #40 in G Minor (3.3.x)
> > > > * Nine Inch Gremlins (3.2.x)
> > > > * A 187 On The Undercover Gremlinz (3.1.x)
> > > > * A Gremlin Rāga in 7/16 Time (3.0.x)
> > > >
> > > > Please submit a name with a logo idea - a name where we can't get a
> > logo
> > > > made doesn't really work too well. Thanks.
> > > >
> > >
> >
>

Re: [DISCUSS] Name of 3.4.x

[Stephen Mallette]

I'm guessing at the reference for "4 Seasons of Gremlin" - are we talking
Boyz || Men and "4 Seasons of Loneliness"?

>  Yeah, I'd like to see what Gremlyn Manson would look like!

would he look that much different than our "Nine Inch Nails Gremlin"?



On Tue, Feb 27, 2018 at 10:58 AM, Robert Dale  wrote:

> Yeah, I'd like to see what Gremlyn Manson would look like!
>
> Robert Dale
>
> On Tue, Feb 27, 2018 at 10:40 AM, Daniel Kuppitz  wrote:
>
> > Four Rusted Gremlins (reference
> > ) :)
> >
> > On Tue, Feb 27, 2018 at 7:47 AM, Stephen Mallette 
> > wrote:
> >
> > > We need a release name and associated Gremlin logo for the 3.4.x series
> > of
> > > TinkerPop. Recall that names should be related to music and include a
> > > number. Thus far we've had:
> > >
> > > * Gremlin Symphony #40 in G Minor (3.3.x)
> > > * Nine Inch Gremlins (3.2.x)
> > > * A 187 On The Undercover Gremlinz (3.1.x)
> > > * A Gremlin Rāga in 7/16 Time (3.0.x)
> > >
> > > Please submit a name with a logo idea - a name where we can't get a
> logo
> > > made doesn't really work too well. Thanks.
> > >
> >
>

Re: [DISCUSS] Gremlin JavaScript release

[Stephen Mallette]

I really think that we need to get as many of the GLV test issues resolved
as possible before the release. I'm not so sure we've even created issues
for all the failures at this point. Some problems haven't even been
classified yet to create a proper issue. I'm going to try to spend some
time on that today. I will addrf Fix Versions to things I think should
close in time for release so that we have an idea as to what needs work:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20TINKERPOP%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(3.2.8%2C%203.3.2)%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC

I'm not sure if that's truly everything we need done, but I figure that
this is a good start. I would also love to see us merge this:

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

Even if we can't implement a ton of GLV examples this would still be
awesome. Unfortunately only some of us can get docker to build docs
appropriately at this point, so that issue needs some resolution.

We probably need a new thread to discuss "release issues" but if any of you
have other ideas for what needs to get done and what doesn't please update
JIRA or make a case for what you're thinking here. Thanks!

On Thu, Mar 1, 2018 at 2:58 AM, Jorge Bay Gondra 
wrote:

> First week of April sounds good to me.
>
> On Fri, Feb 23, 2018 at 12:34 PM, Stephen Mallette 
> wrote:
>
> > Ok - i was just asking for clarity because this thread started as a
> > discussion on a "beta" release.
> >
> > Our last release was in december, so I suppose it would be time to get
> > another one out. I do have a number of issues I'd like to complete for
> > these versions - can we tentatively say that we release first week of
> > April? That would give us about four more weeks of development
> (opportunity
> > to fix more GLV tests across the board plus the other issues I'd like to
> > see done) plus a week of code freeze. is that a good target?
> >
> > On Fri, Feb 23, 2018 at 3:20 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com>
> > wrote:
> >
> > > I'm referring to an official release of all artifacts for versions
> 3.2.8
> > > and 3.3.2. The JavaScript GLV has been reviewed and merged, the test
> > suite
> > > is in good shape. This GLV has been in the pipeline for a long time
> now,
> > I
> > > think we should make the last effort for it to be generally available.
> > >
> > > BTW, npm fixed the issue for the gremlin package:
> > > https://www.npmjs.com/org/tinkerpop
> > >
> > > On Thu, Feb 22, 2018 at 11:03 PM, Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > wrote:
> > >
> > > > You're referring to a gremlin-javascript release candidate and not
> to a
> > > > general official release of all artifacts (java, .net, etc) for
> > > > 3.3.2/3.2.8), right?
> > > >
> > > > On Wed, Feb 21, 2018 at 9:57 AM, Jorge Bay Gondra <
> > > > jorgebaygon...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > > Regarding the npm issue, we created a ticket on the npm issue
> > tracker:
> > > > > https://github.com/npm/registry/issues/281 and contacted support.
> > > > >
> > > > > We are waiting for a response from them, but in any case if it
> takes
> > to
> > > > > long for npm support to look at it, Jean-Baptiste could grant the
> > > > > individual members of tinkerpop:developers / release manager
> access,
> > so
> > > > > that should not be blocking an official release of the JavaScript
> > GLV.
> > > > >
> > > > > Can we start discussing a timeline for 3.2.8/3.3.2?
> > > > >
> > > > > Thanks,
> > > > > Jorge
> > > > >
> > > > > On Tue, Feb 20, 2018 at 10:23 AM, Jorge Bay Gondra <
> > > > > jorgebaygon...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > Any luck?
> > > > > >
> > > > > > On Wed, Feb 14, 2018 at 9:43 AM, Jorge Bay Gondra <
> > > > > > jorgebaygon...@gmail.com> wrote:
> > > > > >
> > > > > >> hm... that's weird... It's working on my end with a different
> > > > package...
> > > > > >>
> > > > > >> Maybe use a newer npm cli version?
> > > > > >>
> > > > > >> If npm access is still failing after cli upgrade, you could use
> > npm
> > > > > owner
> > > > > >>  to add any other tinkerpop
> > > member
> > > > > >>  as co-owner and
> we
> > > > could
> > > > > >> try to run npm access from there.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Tue, Feb 13, 2018 at 4:55 PM, Jean-Baptiste Musso <
> > > > jbmu...@gmail.com
> > > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Getting a 403 Forbidden error:
> > > > > >>>
> > > > > >>> $ npm access grant read-write tinkerpop:developers gremlin
> > > > > >>> npm http request PUT
> > > > > >>> https://registry.npmjs.org/-/team/tinkerpop/developers/package
> > > > > >>> npm http 403 https://registry.npmjs.org/-/t
> > > > > >>> eam/tinkerpop/developers/package
> > > > > >>> npm ERR! code E403
> > > > > >>> npm ERR! Forbidden : 

[jira] [Updated] (TINKERPOP-1891) Serialization of P.not() for gremlin-javascript

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1891:

Fix Version/s: 3.3.2
   3.2.8

> Serialization of P.not() for gremlin-javascript
> ---
>
> Key: TINKERPOP-1891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1891
> Project: TinkerPop
>  Issue Type: Bug
>  Components: javascript
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> There are currently four GLV tests that are currently being ignored in 
> gremlin-javascript as they generate failures on execution:
> https://github.com/apache/tinkerpop/commit/48d459482635dafaf7feef09ffa206357cf4488f
> All of these tests suspiciously all contain a {{P.not()}} so it likely has 
> something to do with that.



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

[jira] [Updated] (TINKERPOP-1895) gremlin-python lambdas do not work with HaltedTraverserStrategy(DetachedFactory)

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1895:

Fix Version/s: 3.3.2
   3.2.8

> gremlin-python lambdas do not work with 
> HaltedTraverserStrategy(DetachedFactory)
> 
>
> Key: TINKERPOP-1895
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1895
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.1
>Reporter: Branden Moore
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> When using the HaltedTraverserStrategy(o.a.t.g.s.u.d.DetachedFactory) in 
> gremlin-python, lambdas cannot be processed, returning a Python NameError.
> Using the examples from the documentation, against 
> gremlin-server-modern-py.yaml
>  
>  g.V().out().map(lambda: "x: len(x.get().value('name'))").sum().toList()
> [24L]
> g.withStrategies(HaltedTraverserStrategy("org.apache.tinkerpop.gremlin.structure.util.detached.DetachedFactory")).V().out().map(lambda:
>  "x: len(x.get().value('name'))").sum().toList()
> GremlinServerError: 599: NameError: name 'TraversalStrategy' is not defined 
> in 

[jira] [Updated] (TINKERPOP-1896) gremlin-python lambdas error when working on Maps

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1896:

Fix Version/s: 3.3.2
   3.2.8

> gremlin-python lambdas error when working on Maps
> -
>
> Key: TINKERPOP-1896
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1896
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.1
>Reporter: Branden Moore
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin-python lambdas throw an error on the server when the preceding step 
> produces maps.
> {code}
> Traceback (most recent call last):
>   File "foo.py", line 15, in 
>     print g.V().has('name').match(__.as_('x').label().as_('lbl'), 
> __.as_('x').id().as_('id')).select('lbl', 'id').map(lambda: "lambda x: 
> type(x)").toList()
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 52, in toList
>     return list(iter(self))
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 70, in next
>     return self.__next__()
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 43, in __next__
>     self.traversal_strategies.apply_strategies(self)
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py",
>  line 352, in apply_strategies
>     traversal_strategy.apply(traversal)
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/remote_connection.py",
>  line 143, in apply
>     remote_traversal = self.remote_connection.submit(traversal.bytecode)
>   File 
> "/user/.local/lib/python2.7/site-packages/gremlin_python/driver/driver_remote_connection.py",
>  line 54, in submit
>     results = result_set.all().result()
>   File 
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 
> 462, in result
>     return self.__get_result()
>   File 
> "/user/.local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 
> 414, in __get_result
>     raise exception_type, self._exception, self._traceback
> gremlin_python.driver.protocol.GremlinServerError: 599: AttributeError: type 
> object 'org.apache.tinkerpop.gremlin.process.traversal.dsl' has no attribute 
> 'as_' in 

[jira] [Updated] (TINKERPOP-1859) Complex instance of P not serializing to bytecode properly

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1859:

Fix Version/s: 3.3.2
   3.2.8

> Complex instance of P not serializing to bytecode properly
> --
>
> Key: TINKERPOP-1859
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1859
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Not sure what's happening but this traversal does not return any results with 
> gremlin-python:
> {code}
> gremlin> g.V().hasLabel("person").has("age", 
> P.not(P.lte(10).and(P.not(P.between(11, 
> 20.and(P.lt(29).or(P.eq(35.values("name")
> ==>vadas
> ==>peter
> {code}
> When looking at the bytecode the python bytecode is different from the java 
> bytecode. The java bytecode for the predicate is:
> {code}
> {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "and",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": "or",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": "gt",
>   "value": {
>   "@type": "g:Int32",
>   "@value": 10
>   }
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "and",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": 
> "gte",
>   "value": {
>   
> "@type": "g:Int32",
>   
> "@value": 11
>   }
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": 
> "lt",
>   "value": {
>   
> "@type": "g:Int32",
>   
> "@value": 20
>   }
>   }
>   }]
>   }
>   }]
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "or",
>   "value": [{
>   "@type": "g:P",
>   "@value": {
>   "predicate": "lt",
>   "value": {
>   "@type": "g:Int32",
>   "@value": 29
>   }
>   }
>   }, {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "eq",
>   "value": {
>   "@type": "g:Int32",
>   "@value": 35
>   }
>   }
>   }]
>   }
>   }]
>   }
> }
> {code}
> The python bytecode is:
> {code}
> {
>   "@type": "g:P",
>   "@value": {
>   "predicate": "and",
> 

[jira] [Updated] (TINKERPOP-1894) GraphSONMessageSerializerV2d0 fails to deserialize valid P.not()

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1894:

Component/s: io

> GraphSONMessageSerializerV2d0 fails to deserialize valid P.not()
> 
>
> Key: TINKERPOP-1894
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1894
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Jorge Bay
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> GraphSONMessageSerializerV2d0 is not able to deserialize a {{g : P}} 
> predicate for not.
> You can use the following test to reproduce it:
> {code:java}
> public class GraphSONMessageSerializerV2d0Test {
> // ...
> @Test
> public void shouldDeserializeNotPredicate() throws Exception {
> final RequestMessage m = 
> SERIALIZER.deserializeRequest("{\"requestId\":{\"@type\":\"g:UUID\",\"@value\":\"0397b9c0-ffab-470e-a6a8-644fc80c01d6\"},\"op\":\"bytecode\",\"processor\":\"traversal\",\"args\":{\"gremlin\":{\"@type\":\"g:Bytecode\",\"@value\":{\"step\":[[\"V\"],[\"hasLabel\",\"person\"],[\"has\",\"age\",{\"@type\":\"g:P\",\"@value\":{\"predicate\":\"not\",\"value\":{\"@type\":\"g:P\",\"@value\":{\"predicate\":\"lte\",\"value\":{\"@type\":\"g:Int32\",\"@value\":10}]]}},\"aliases\":{\"g\":\"gmodern\"}}}");
> assertEquals("bytecode", m.getOp());
> assertNotNull(m.getArgs());
> }
> }
> {code}
> The error message:
> {code}
>   at 
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0.deserializeRequest(GraphSONMessageSerializerV2d0.java:103)
>   at 
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0Test.shouldDeserializeNotPredicate(GraphSONMessageSerializerV2d0Test.java:367)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: 
> Could not deserialize the JSON value as required. Nested exception: 
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not 
> deserialize the JSON value as required. Nested exception: 
> java.lang.IllegalStateException: 
> org.apache.tinkerpop.gremlin.process.traversal.P.not([Ljava.lang.Object;)
>  at [Source: 
> {"requestId":{"@type":"g:UUID","@value":"0397b9c0-ffab-470e-a6a8-644fc80c01d6"},"op":"bytecode","processor":"traversal","args":{"gremlin":{"@type":"g:Bytecode","@value":{"step":[["V"],["hasLabel","person"],["has","age",{"@type":"g:P","@value":{"predicate":"not","value":{"@type":"g:P","@value":{"predicate":"lte","value":{"@type":"g:Int32","@value":10}]]}},"aliases":{"g":"gmodern"}}};
>  line: 1, 

[jira] [Updated] (TINKERPOP-1894) GraphSONMessageSerializerV2d0 fails to deserialize valid P.not()

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1894:

Fix Version/s: 3.3.2
   3.2.8

> GraphSONMessageSerializerV2d0 fails to deserialize valid P.not()
> 
>
> Key: TINKERPOP-1894
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1894
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Jorge Bay
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> GraphSONMessageSerializerV2d0 is not able to deserialize a {{g : P}} 
> predicate for not.
> You can use the following test to reproduce it:
> {code:java}
> public class GraphSONMessageSerializerV2d0Test {
> // ...
> @Test
> public void shouldDeserializeNotPredicate() throws Exception {
> final RequestMessage m = 
> SERIALIZER.deserializeRequest("{\"requestId\":{\"@type\":\"g:UUID\",\"@value\":\"0397b9c0-ffab-470e-a6a8-644fc80c01d6\"},\"op\":\"bytecode\",\"processor\":\"traversal\",\"args\":{\"gremlin\":{\"@type\":\"g:Bytecode\",\"@value\":{\"step\":[[\"V\"],[\"hasLabel\",\"person\"],[\"has\",\"age\",{\"@type\":\"g:P\",\"@value\":{\"predicate\":\"not\",\"value\":{\"@type\":\"g:P\",\"@value\":{\"predicate\":\"lte\",\"value\":{\"@type\":\"g:Int32\",\"@value\":10}]]}},\"aliases\":{\"g\":\"gmodern\"}}}");
> assertEquals("bytecode", m.getOp());
> assertNotNull(m.getArgs());
> }
> }
> {code}
> The error message:
> {code}
>   at 
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0.deserializeRequest(GraphSONMessageSerializerV2d0.java:103)
>   at 
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0Test.shouldDeserializeNotPredicate(GraphSONMessageSerializerV2d0Test.java:367)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: 
> Could not deserialize the JSON value as required. Nested exception: 
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not 
> deserialize the JSON value as required. Nested exception: 
> java.lang.IllegalStateException: 
> org.apache.tinkerpop.gremlin.process.traversal.P.not([Ljava.lang.Object;)
>  at [Source: 
> 

[jira] [Updated] (TINKERPOP-1898) Issue with bindings in strategies and lambdas

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1898:

Fix Version/s: 3.3.2
   3.2.8

> Issue with bindings in strategies and lambdas
> -
>
> Key: TINKERPOP-1898
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1898
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python, server
>Affects Versions: 3.3.1
>Reporter: Jean-Philippe Braun
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
> Attachments: bug.py
>
>
> I'm trying to use bindings in a traversal strategy like:
> {code:java}
>     graph = Graph()
>     g = 
> graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin',
>  'g'))
>     g = g.withStrategies(
>     SubgraphStrategy(vertices=__.has('foo', ('b', 5)))
>     ){code}
> This works unless there is a use of lambda in the traversal:
> {code:java}
>     g.V().toList() # will work
>     g.V().filter(lambda: "true").toList() # this will not{code}
> Here is the full TB on the server:
> {code:java}
>     [ERROR] TraversalOpProcessor - Could not deserialize the Traversal 
> instance
>     javax.script.ScriptException: javax.script.ScriptException: 
> groovy.lang.MissingPropertyException: No such property: b for class: Script4
>     at 
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:397)
>     at 
> javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233)
>     at 
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:309)
>     at 
> org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.eval(GremlinExecutor.java:343)
>     at 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateBytecodeTraversal(TraversalOpProcessor.java:369)
>     at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
>     at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:43)
>     at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
>     at 
> io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
>     at 
> 

[jira] [Updated] (TINKERPOP-1854) Support lambdas in Gremlin.Net

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1854:

Fix Version/s: 3.3.2
   3.2.8

As we have a pull request open for this one, I think we should try to get it 
closed in time for release of 3.2.8/3.3.2 (currently targetting for first week 
of april)

> Support lambdas in Gremlin.Net
> --
>
> Key: TINKERPOP-1854
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1854
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> Gremlin.Net should support lambdas. We already discussed this in [the pull 
> request for TINKERPOP-1752|https://github.com/apache/tinkerpop/pull/712]. 
> Here is what [~spmallette] said over there:
> {quote}
> Any reason we don't support lambdas? Even if .NET can't support them natively 
> for some reason wouldn't we minimally support the ability to pass a 
> python/groovy/etc lambda? it's kinda weird that way, but i think back to the 
> point that kuppitz made on the dev list the other day where he stated that he 
> doesn't always find a way out of using lambdas in production systems he works 
> on - so ultimately users will need that kind of capability i think.
> {quote}
> C# lambdas would require some kind of C# parser on the server side, so at 
> least in the beginning a way to send lambdas from already supported languages 
> in Gremlin.Net should be enough.



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

[jira] [Updated] (TINKERPOP-1885) Various Gremlin.Net documentation updates

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1885:

Fix Version/s: 3.3.2
   3.2.8

> Various Gremlin.Net documentation updates
> -
>
> Key: TINKERPOP-1885
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1885
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation, dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Priority: Trivial
> Fix For: 3.2.8, 3.3.2
>
>
> We have some parts of the documentation regarding Gremlin.Net that should be 
> updated now that we have a stable release:
>  * Homepage: _Query Languages_ misses a reference to Gremlin.Net
>  * Homepage: _Language Drivers_ section still links to the repository on my 
> private account. It should probably link to the Gremlin.Net section in the 
> reference docs or to a {{README}} (see below).
>  * Reference docs still contain a warning that _Gremlin.Net does not yet have 
> an official release._
>  * Add a {{README}} that explains Gremlin.Net, similar to the documents we 
> have for the Python and Javascript GLVs.
>  * The {{csproj}} file contains a pretty extensive {{summary}} element, but 
> {{summary}} isn't part of the {{csproj}} standard. So it isn't used for 
> anything. It should be merged into the {{description}} element instead.



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

[jira] [Commented] (TINKERPOP-1885) Various Gremlin.Net documentation updates

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1885:
-

Gravatar image is setup for nuget. 

As for a ".NET Gremlin", I think that for now you could just use the standard 
Microsoft .NET logo like this:

https://s3.amazonaws.com/production-wordpress-assets/blog/wp-content/uploads/2017/02/23082646/Microsoft-dotNET-logo.jpg

or something similar. [~Florian Hockmann] do you have time soon to get the 
README in place so that we can get this one closed?

> Various Gremlin.Net documentation updates
> -
>
> Key: TINKERPOP-1885
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1885
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation, dotnet
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>Priority: Trivial
>
> We have some parts of the documentation regarding Gremlin.Net that should be 
> updated now that we have a stable release:
>  * Homepage: _Query Languages_ misses a reference to Gremlin.Net
>  * Homepage: _Language Drivers_ section still links to the repository on my 
> private account. It should probably link to the Gremlin.Net section in the 
> reference docs or to a {{README}} (see below).
>  * Reference docs still contain a warning that _Gremlin.Net does not yet have 
> an official release._
>  * Add a {{README}} that explains Gremlin.Net, similar to the documents we 
> have for the Python and Javascript GLVs.
>  * The {{csproj}} file contains a pretty extensive {{summary}} element, but 
> {{summary}} isn't part of the {{csproj}} standard. So it isn't used for 
> anything. It should be merged into the {{description}} element instead.



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

[jira] [Updated] (TINKERPOP-1865) Run Gremlin .NET GLV tests with GraphSON 3.0

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1865:

Fix Version/s: 3.3.2

> Run Gremlin .NET GLV tests with GraphSON 3.0
> 
>
> Key: TINKERPOP-1865
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1865
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.3.2
>
>
> GLV tests currently run for GraphSON 2.0 with .NET - they should be running 
> for 3.0 especially on the 3.3.x line of code. Ideally we should probably run 
> tests for both versions, but perhaps that is a separate issue at this point 
> as it is for Python on TINKERPOP-1864



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