Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Marko Rodriguez]

Hi,

However, in general we just need an “object mapper pattern.” For instance:

For any JSON object { } that has a @type field, the @type value maps to a 
deserializer. Thus, while we need to be able to serialize/deserialize the 
standard Vertex/Edge/VertexProperty/etc. the representation should be 
generalized to support any registered @type.

Java GraphSON serializer/deserializer registration:

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L129-L147
 


Python GraphSON serializer registration:

https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-python/src/main/jython/gremlin_python/process/graphson.py#L122-L127
 


People can register more @types as needed for their graph processor’s type 
system.

Marko.

http://markorodriguez.com



> On Jul 19, 2016, at 12:55 PM, Marko Rodriguez  wrote:
> 
> We need:
> 
>   Graph
>   Element
>   Vertex
>   Edge
>   VertexProperty
>   Property
>   Path
>   TraversalExplanation
>   TraversalMetrics
>   Traversal (i.e. Bytecode)
>   Traverser (object + bulk at minimum)
> 
> Marko.
> 
> http://markorodriguez.com
> 
> 
> 
>> On Jul 19, 2016, at 12:45 PM, Robert Dale  wrote:
>> 
>> There's also Path that can be returned from a query. It looks like
>> GraphSON 1.0 handles this today in the REST API but it's not typed as
>> a path.
>> 
>> On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com
>>  wrote:
>>> 
>>> 
>>> On 2016-07-19 18:02 (+0100), Robert Dale  wrote:
 - It seems redundant to nest a vertex or edge inside a type-value
 object and is inconsistent with a VertexProperty.
 - VertexProperty and (edge) Property are implicit types. I don't know
 if this is ok. Could they ever be used outside of their parents where
 they would need to be typed?
>>> 
>>> I agree with the VertexProperty remark. That's one last question I wanted 
>>> to solve, if we go for typing Vertex and edges, do we include others? The 
>>> full list I see then is : vertex/edge/vertexproperty/property/graph.
>>> 
>>> However I am not sure how useful it is to have more than Vertex and Edge. 
>>> As, when deserializing a Vertex for example, there's no question as to what 
>>> is in the "properties" field of the Vertex, there are necessarily only 
>>> VertexProperties. However looking at the API, it seems like it is supported 
>>> to write only a VertexProperty if one wants to (see 
>>> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense 
>>> to add the types for the elements of the list I described above. @stephen 
>>> any thoughts about that ?
>>> 
 - Edges:
 - is in/outVLabel new? Couldn't find it in the API or any examples of this.
 - why not make inV/outV have proper vertices with labels (to satisfy
 the case previous case) instead of just IDs? This would also be more
 consistent with the API.
>>> 
>>> I haven't touched that part, it was in the format before. I believe this is 
>>> a question for Stephen.
>>> 
 
 Otherwise looks good!
>>> 
>>> Thanks for the feedback.
 
 On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
  wrote:
> 
> 
> On 2016-07-15 16:25 (+0100), 
> "gallardo.kev...@gmail.com" wrote:
>> 
>> 
>> On 2016-07-09 16:48 (+0100), Stephen Mallette  
>> wrote:
>>> With all the work on GLVs and the recent work on GraphSON 2.0, I think 
>>> it's
>>> important that we have a solid, efficient, programming language neutral,
>>> lossless serialization format. Right now that format is GraphSON and it
>>> works for that purpose (ever more  so with 2.0). Given some discussion 
>>> on
>>> the GraphSON 2.0 PR driven a bit by Robert Dale:
>>> 
>>> https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
>>> 
>>> I wonder if we shouldn't consider another IO format that has Gremlin
>>> Server/GLVs in mind. At this point I'm not suggesting anything specific 
>>> -
>>> I'm just hanging the idea out for further discussion and brain storming.
>>> Thoughts?
>>> 
>> 
>> Hey, so I'm trying to gather all infos we have here in order to prepare 
>> to move forward with the implem of GraphSON 2.0, here's what I come up 
>> with :
>> 
>> Things we have :
>> - Type format.
>> - The structure in 

[jira] [Updated] (TINKERPOP-1379) unaccounted excess in TailGlobalStep

[Jason Plurad (JIRA)]

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

Jason Plurad updated TINKERPOP-1379:

Description: 
https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74

This code doesn't account for the excess removed from {{tailBulk}}. This can 
cause the code to set incorrect bulk values when there are multiple traversers 
in the tail buffer.

I observed this behavior intermittently in TitanGraph 
(https://github.com/thinkaurelius/titan/pull/1312), which doesn't allow user 
defined ids, so the ordering of the traversers in the TraverserSet is a lot 
more random than the unit tests using TinkerGraph.

This issue is reproducible with TinkerGraph (master/3.2.1). Instead of loading 
from one of the data files, manually create the graph with the ids in inverted 
order.
{noformat}
graph = TinkerGraph.open();

// graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", "marko", 
"age", 29);
final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", "vadas", 
"age", 27);
final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", "lop", 
"lang", "java");
final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", "josh", 
"age", 32);
final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
"ripple", "lang", "java");
final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", "peter", 
"age", 35);
v1.addEdge("knows", v2, "weight", 0.5d);
v1.addEdge("knows", v4, "weight", 1.0d);
v1.addEdge("created", v2, "weight", 0.4d);
v4.addEdge("knows", v5, "weight", 1.0d);
v4.addEdge("knows", v3, "weight", 0.4d);
v6.addEdge("knows", v3, "weight", 0.2d);
if (graph.features().graph().supportsTransactions()) graph.tx().commit();

final GraphTraversalSource g = graph.traversal();
String result = g.V().repeat(both()).times(3).tail(7).count().next().toString();
boolean success = "7".equals(result);
{noformat}

The fix is this:
{noformat}
if (excess > 0) {
oldest.setBulk(oldestBulk-excess);
// Account for the loss of excess in the tail buffer
this.tailBulk -= excess;
}
{noformat}

  was:
https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74

This code doesn't account for the excess removed from {{tailBulk}}. This can 
cause the code to set incorrect bulk values when there are multiple traversers 
in the tail buffer.

I observed this behavior intermittently in TitanGraph, which doesn't allow user 
defined ids, so the ordering of the traversers in the TraverserSet is a lot 
more random than the unit tests using TinkerGraph.

This issue is reproducible with TinkerGraph (master/3.2.1). Instead of loading 
from one of the data files, manually create the graph with the ids in inverted 
order.
{noformat}
graph = TinkerGraph.open();

// graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", "marko", 
"age", 29);
final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", "vadas", 
"age", 27);
final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", "lop", 
"lang", "java");
final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", "josh", 
"age", 32);
final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
"ripple", "lang", "java");
final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", "peter", 
"age", 35);
v1.addEdge("knows", v2, "weight", 0.5d);
v1.addEdge("knows", v4, "weight", 1.0d);
v1.addEdge("created", v2, "weight", 0.4d);
v4.addEdge("knows", v5, "weight", 1.0d);
v4.addEdge("knows", v3, "weight", 0.4d);
v6.addEdge("knows", v3, "weight", 0.2d);
if (graph.features().graph().supportsTransactions()) graph.tx().commit();

final GraphTraversalSource g = graph.traversal();
String result = g.V().repeat(both()).times(3).tail(7).count().next().toString();
boolean success = "7".equals(result);
{noformat}

The fix is this:
{noformat}
if (excess > 0) {
oldest.setBulk(oldestBulk-excess);
// Account for the loss of excess in the tail buffer
this.tailBulk -= excess;
}
{noformat}


> unaccounted excess in TailGlobalStep
> 
>
> Key: TINKERPOP-1379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1379
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Jason Plurad
>
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74
> This code doesn't account for the 

[jira] [Created] (TINKERPOP-1379) unaccounted excess in TailGlobalStep

[Jason Plurad (JIRA)]

Jason Plurad created TINKERPOP-1379:
---

 Summary: unaccounted excess in TailGlobalStep
 Key: TINKERPOP-1379
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1379
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.2.1
Reporter: Jason Plurad


https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/TailGlobalStep.java#L71-L74

This code doesn't account for the excess removed from {{tailBulk}}. This can 
cause the code to set incorrect bulk values when there are multiple traversers 
in the tail buffer.

I observed this behavior intermittently in TitanGraph, which doesn't allow user 
defined ids, so the ordering of the traversers in the TraverserSet is a lot 
more random than the unit tests using TinkerGraph.

This issue is reproducible with TinkerGraph (master/3.2.1). Instead of loading 
from one of the data files, manually create the graph with the ids in inverted 
order.
{noformat}
graph = TinkerGraph.open();

// graph.io(IoCore.gryo()).readGraph("tinkerpop-modern.kryo");
final Vertex v1 = graph.addVertex(T.id, 6L, T.label, "person", "name", "marko", 
"age", 29);
final Vertex v2 = graph.addVertex(T.id, 5L, T.label, "person", "name", "vadas", 
"age", 27);
final Vertex v3 = graph.addVertex(T.id, 4L, T.label, "software", "name", "lop", 
"lang", "java");
final Vertex v4 = graph.addVertex(T.id, 3L, T.label, "person", "name", "josh", 
"age", 32);
final Vertex v5 = graph.addVertex(T.id, 2L, T.label, "software", "name", 
"ripple", "lang", "java");
final Vertex v6 = graph.addVertex(T.id, 1L, T.label, "person", "name", "peter", 
"age", 35);
v1.addEdge("knows", v2, "weight", 0.5d);
v1.addEdge("knows", v4, "weight", 1.0d);
v1.addEdge("created", v2, "weight", 0.4d);
v4.addEdge("knows", v5, "weight", 1.0d);
v4.addEdge("knows", v3, "weight", 0.4d);
v6.addEdge("knows", v3, "weight", 0.2d);
if (graph.features().graph().supportsTransactions()) graph.tx().commit();

final GraphTraversalSource g = graph.traversal();
String result = g.V().repeat(both()).times(3).tail(7).count().next().toString();
boolean success = "7".equals(result);
{noformat}

The fix is this:
{noformat}
if (excess > 0) {
oldest.setBulk(oldestBulk-excess);
// Account for the loss of excess in the tail buffer
this.tailBulk -= excess;
}
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] TinkerPop 3.2.1 Release

[Daniel Kuppitz]

$ bin/validate-distribution.sh 3.2.1

Validating binary distributions

* downloading Apache Gremlin Console
(apache-gremlin-console-3.2.1-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache Gremlin Console ... OK
* validating Apache Gremlin Console's docs ... OK
* validating Apache Gremlin Console's binaries ... OK
* validating Apache Gremlin Console's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache Gremlin Console's plugin directory ... OK
* validating Apache Gremlin Console's lib directory ... OK
* testing script evaluation ... OK

* downloading Apache Gremlin Server
(apache-gremlin-server-3.2.1-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache Gremlin Server ... OK
* validating Apache Gremlin Server's docs ... OK
* validating Apache Gremlin Server's binaries ... OK
* validating Apache Gremlin Server's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache Gremlin Server's plugin directory ... OK
* validating Apache Gremlin Server's lib directory ... OK

Validating source distribution

* downloading Apache TinkerPop 3.2.1 (apache-tinkerpop-3.2.1-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop 3.2.1 ... OK
OK



Also did a bunch of manual tests (using the console). All good.

VOTE: +1

Cheers,
Daniel


On Tue, Jul 19, 2016 at 9:19 PM, Dylan Millikin 
wrote:

> Ran all the driver tests again neo4j and tinkerpop and everything works as
> expected.
>
> VOTE: +1
>
> On Tue, Jul 19, 2016 at 9:20 AM, Stephen Mallette 
> wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.2.1 is ready for release - note
> > the lack of "-incubating" everywhere.  :)
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.1/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.1-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-gremlin-console-3.2.1-bin.zip
> > apache-gremlin-server-3.2.1-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.2.1/reference/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.1/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.1/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.1/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=c5a9e2815e76f044e6b33b773b6bb0bb048270cc
> >
> > The release notes are available here:
> >
> >
> https://github.com/apache/tinkerpop/blob/3.2.1/CHANGELOG.asciidoc#release-3-2-1
> >
> > The [VOTE] will be open for the next 72 hours --- closing Friday (July
> 22,
> > 2016) at 9:30 am EST.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Stephen
> >
>

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Stephen Mallette]

ah - sorry - didn't follow that. that makes sense to me. inVLabel and
outVLabel are kinda awkward. +1 from me on that one.

On Tue, Jul 19, 2016 at 3:23 PM, Robert Dale  wrote:

> On Tue, Jul 19, 2016 at 3:13 PM, Stephen Mallette 
> wrote:
> >>
> >> > - VertexProperty and (edge) Property are implicit types. I don't know
> >> > if this is ok. Could they ever be used outside of their parents where
> >> > they would need to be typed?
> >>
> >> I agree with the VertexProperty remark. That's one last question I
> wanted
> >> to solve, if we go for typing Vertex and edges, do we include others?
> The
> >> full list I see then is : vertex/edge/vertexproperty/property/graph.
> >>
> >> However I am not sure how useful it is to have more than Vertex and
> Edge.
> >> As, when deserializing a Vertex for example, there's no question as to
> what
> >> is in the "properties" field of the Vertex, there are necessarily only
> >> VertexProperties. However looking at the API, it seems like it is
> supported
> >> to write only a VertexProperty if one wants to (see
> >> GraphWriter.writeVertexProperty()), so in that case, to me it makes
> sense
> >> to add the types for the elements of the list I described above.
> @stephen
> >> any thoughts about that ?
> >
> >
> > I guess we should type them to be consistent and because they might
> return
> > independently of a Vertex/Edge as Robert suggests.
> >
> >> - Edges:
> >> >   - is in/outVLabel new? Couldn't find it in the API or any examples
> of
> >> this.
> >> >   - why not make inV/outV have proper vertices with labels (to satisfy
> >> > the case previous case) instead of just IDs? This would also be more
> >> > consistent with the API.
> >>
> >> I haven't touched that part, it was in the format before. I believe this
> >> is a question for Stephen.
> >
> >
> > Returning a "proper" vertex for inV/outV would be nice but it's
> potentially
> > forcing the underlying graph database to pull a lot of data when the user
> > only requested an edge to be returned. I don't think we should go that
> far.
>
> By "proper" I meant an object (type: vertex) that would have the data
> that's already available - label, id.  No extra trips to the db. Just
> more intuitive packaging of that data.
>
> --
> Robert Dale
>

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Robert Dale]

On Tue, Jul 19, 2016 at 3:13 PM, Stephen Mallette  wrote:
>>
>> > - VertexProperty and (edge) Property are implicit types. I don't know
>> > if this is ok. Could they ever be used outside of their parents where
>> > they would need to be typed?
>>
>> I agree with the VertexProperty remark. That's one last question I wanted
>> to solve, if we go for typing Vertex and edges, do we include others? The
>> full list I see then is : vertex/edge/vertexproperty/property/graph.
>>
>> However I am not sure how useful it is to have more than Vertex and Edge.
>> As, when deserializing a Vertex for example, there's no question as to what
>> is in the "properties" field of the Vertex, there are necessarily only
>> VertexProperties. However looking at the API, it seems like it is supported
>> to write only a VertexProperty if one wants to (see
>> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense
>> to add the types for the elements of the list I described above. @stephen
>> any thoughts about that ?
>
>
> I guess we should type them to be consistent and because they might return
> independently of a Vertex/Edge as Robert suggests.
>
>> - Edges:
>> >   - is in/outVLabel new? Couldn't find it in the API or any examples of
>> this.
>> >   - why not make inV/outV have proper vertices with labels (to satisfy
>> > the case previous case) instead of just IDs? This would also be more
>> > consistent with the API.
>>
>> I haven't touched that part, it was in the format before. I believe this
>> is a question for Stephen.
>
>
> Returning a "proper" vertex for inV/outV would be nice but it's potentially
> forcing the underlying graph database to pull a lot of data when the user
> only requested an edge to be returned. I don't think we should go that far.

By "proper" I meant an object (type: vertex) that would have the data
that's already available - label, id.  No extra trips to the db. Just
more intuitive packaging of that data.

-- 
Robert Dale

Re: [VOTE] TinkerPop 3.2.1 Release

[Dylan Millikin]

Ran all the driver tests again neo4j and tinkerpop and everything works as
expected.

VOTE: +1

On Tue, Jul 19, 2016 at 9:20 AM, Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.2.1 is ready for release - note
> the lack of "-incubating" everywhere.  :)
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.1/
>
> The source distribution is provided by:
> apache-tinkerpop-3.2.1-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-gremlin-console-3.2.1-bin.zip
> apache-gremlin-server-3.2.1-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
> http://tinkerpop.apache.org/docs/3.2.1/reference/ (user docs)
> http://tinkerpop.apache.org/docs/3.2.1/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.2.1/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.2.1/full/ (full javadoc)
>
> The tag in Apache Git can be found here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=c5a9e2815e76f044e6b33b773b6bb0bb048270cc
>
> The release notes are available here:
>
> https://github.com/apache/tinkerpop/blob/3.2.1/CHANGELOG.asciidoc#release-3-2-1
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (July 22,
> 2016) at 9:30 am EST.
>
> My vote is +1.
>
> Thank you very much,
> Stephen
>

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Stephen Mallette]

>
> > - VertexProperty and (edge) Property are implicit types. I don't know
> > if this is ok. Could they ever be used outside of their parents where
> > they would need to be typed?
>
> I agree with the VertexProperty remark. That's one last question I wanted
> to solve, if we go for typing Vertex and edges, do we include others? The
> full list I see then is : vertex/edge/vertexproperty/property/graph.
>
> However I am not sure how useful it is to have more than Vertex and Edge.
> As, when deserializing a Vertex for example, there's no question as to what
> is in the "properties" field of the Vertex, there are necessarily only
> VertexProperties. However looking at the API, it seems like it is supported
> to write only a VertexProperty if one wants to (see
> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense
> to add the types for the elements of the list I described above. @stephen
> any thoughts about that ?


I guess we should type them to be consistent and because they might return
independently of a Vertex/Edge as Robert suggests.

> - Edges:
> >   - is in/outVLabel new? Couldn't find it in the API or any examples of
> this.
> >   - why not make inV/outV have proper vertices with labels (to satisfy
> > the case previous case) instead of just IDs? This would also be more
> > consistent with the API.
>
> I haven't touched that part, it was in the format before. I believe this
> is a question for Stephen.


Returning a "proper" vertex for inV/outV would be nice but it's potentially
forcing the underlying graph database to pull a lot of data when the user
only requested an edge to be returned. I don't think we should go that far.


On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com <
gallardo.kev...@gmail.com> wrote:

>
>
> On 2016-07-19 18:02 (+0100), Robert Dale  wrote:
> > - It seems redundant to nest a vertex or edge inside a type-value
> > object and is inconsistent with a VertexProperty.
> > - VertexProperty and (edge) Property are implicit types. I don't know
> > if this is ok. Could they ever be used outside of their parents where
> > they would need to be typed?
>
> I agree with the VertexProperty remark. That's one last question I wanted
> to solve, if we go for typing Vertex and edges, do we include others? The
> full list I see then is : vertex/edge/vertexproperty/property/graph.
>
> However I am not sure how useful it is to have more than Vertex and Edge.
> As, when deserializing a Vertex for example, there's no question as to what
> is in the "properties" field of the Vertex, there are necessarily only
> VertexProperties. However looking at the API, it seems like it is supported
> to write only a VertexProperty if one wants to (see
> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense
> to add the types for the elements of the list I described above. @stephen
> any thoughts about that ?
>
> > - Edges:
> >   - is in/outVLabel new? Couldn't find it in the API or any examples of
> this.
> >   - why not make inV/outV have proper vertices with labels (to satisfy
> > the case previous case) instead of just IDs? This would also be more
> > consistent with the API.
>
> I haven't touched that part, it was in the format before. I believe this
> is a question for Stephen.
>
> >
> > Otherwise looks good!
>
> Thanks for the feedback.
> >
> > On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
> >  wrote:
> > >
> > >
> > > On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com"<
> gallardo.kev...@gmail.com> wrote:
> > >>
> > >>
> > >> On 2016-07-09 16:48 (+0100), Stephen Mallette 
> wrote:
> > >> > With all the work on GLVs and the recent work on GraphSON 2.0, I
> think it's
> > >> > important that we have a solid, efficient, programming language
> neutral,
> > >> > lossless serialization format. Right now that format is GraphSON
> and it
> > >> > works for that purpose (ever more  so with 2.0). Given some
> discussion on
> > >> > the GraphSON 2.0 PR driven a bit by Robert Dale:
> > >> >
> > >> > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> > >> >
> > >> > I wonder if we shouldn't consider another IO format that has Gremlin
> > >> > Server/GLVs in mind. At this point I'm not suggesting anything
> specific -
> > >> > I'm just hanging the idea out for further discussion and brain
> storming.
> > >> > Thoughts?
> > >> >
> > >>
> > >> Hey, so I'm trying to gather all infos we have here in order to
> prepare to move forward with the implem of GraphSON 2.0, here's what I come
> up with :
> > >>
> > >> Things we have :
> > >> - Type format.
> > >> - The structure in Jackson to implement our own type format.
> > >> - All non native Graph types are typed (except the domain specific
> types).
> > >>
> > >> New things we need :
> > >> - Types for domain specific objects.
> > >> - Types for all numeric values.
> > >> - Don't serialize empty fields (outV and 

[jira] [Created] (TINKERPOP-1378) Provide a config for Optout

[pieter martin (JIRA)]

pieter martin created TINKERPOP-1378:


 Summary: Provide a config for Optout
 Key: TINKERPOP-1378
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1378
 Project: TinkerPop
  Issue Type: Improvement
  Components: test-suite
Affects Versions: 3.2.2
Reporter: pieter martin
Priority: Minor


Currently the {{OptOut}} annotations are specified directly in the main Graph 
implementation.

This ticket is to think of a way to specify the {{OptOut}}s in a configuration 
file with test scope.

A further concern is to add an additional parameter to the configuration to 
name the test suite that the {{OptOut}} applies to.

The reasoning behind this is that an implementation might itself have different 
underlying databases with different behavior. So by example, 
{{SqlgHsqldbProcessStandardTest}} might {{OptOut}} of different tests to 
{{SqlgGraphPostgresProcessStandardTest}}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Robert Dale]

There's also Path that can be returned from a query. It looks like
GraphSON 1.0 handles this today in the REST API but it's not typed as
a path.

On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com
 wrote:
>
>
> On 2016-07-19 18:02 (+0100), Robert Dale  wrote:
>> - It seems redundant to nest a vertex or edge inside a type-value
>> object and is inconsistent with a VertexProperty.
>> - VertexProperty and (edge) Property are implicit types. I don't know
>> if this is ok. Could they ever be used outside of their parents where
>> they would need to be typed?
>
> I agree with the VertexProperty remark. That's one last question I wanted to 
> solve, if we go for typing Vertex and edges, do we include others? The full 
> list I see then is : vertex/edge/vertexproperty/property/graph.
>
> However I am not sure how useful it is to have more than Vertex and Edge. As, 
> when deserializing a Vertex for example, there's no question as to what is in 
> the "properties" field of the Vertex, there are necessarily only 
> VertexProperties. However looking at the API, it seems like it is supported 
> to write only a VertexProperty if one wants to (see 
> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense to 
> add the types for the elements of the list I described above. @stephen any 
> thoughts about that ?
>
>> - Edges:
>>   - is in/outVLabel new? Couldn't find it in the API or any examples of this.
>>   - why not make inV/outV have proper vertices with labels (to satisfy
>> the case previous case) instead of just IDs? This would also be more
>> consistent with the API.
>
> I haven't touched that part, it was in the format before. I believe this is a 
> question for Stephen.
>
>>
>> Otherwise looks good!
>
> Thanks for the feedback.
>>
>> On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
>>  wrote:
>> >
>> >
>> > On 2016-07-15 16:25 (+0100), 
>> > "gallardo.kev...@gmail.com" wrote:
>> >>
>> >>
>> >> On 2016-07-09 16:48 (+0100), Stephen Mallette  
>> >> wrote:
>> >> > With all the work on GLVs and the recent work on GraphSON 2.0, I think 
>> >> > it's
>> >> > important that we have a solid, efficient, programming language neutral,
>> >> > lossless serialization format. Right now that format is GraphSON and it
>> >> > works for that purpose (ever more  so with 2.0). Given some discussion 
>> >> > on
>> >> > the GraphSON 2.0 PR driven a bit by Robert Dale:
>> >> >
>> >> > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
>> >> >
>> >> > I wonder if we shouldn't consider another IO format that has Gremlin
>> >> > Server/GLVs in mind. At this point I'm not suggesting anything specific 
>> >> > -
>> >> > I'm just hanging the idea out for further discussion and brain storming.
>> >> > Thoughts?
>> >> >
>> >>
>> >> Hey, so I'm trying to gather all infos we have here in order to prepare 
>> >> to move forward with the implem of GraphSON 2.0, here's what I come up 
>> >> with :
>> >>
>> >> Things we have :
>> >> - Type format.
>> >> - The structure in Jackson to implement our own type format.
>> >> - All non native Graph types are typed (except the domain specific types).
>> >>
>> >> New things we need :
>> >> - Types for domain specific objects.
>> >> - Types for all numeric values.
>> >> - Don't serialize empty fields (outV and stuff).
>> >>
>> >> Things we consider changing :
>> >> - Type IDs convention. Before : Java simple class names. Now : starts 
>> >> with a "domain" like "gremlin" followed by the "type name", which is a 
>> >> lowercased type name (like "uuid", or "float", or "vertex"). Example : 
>> >> "gremlin:uuid".
>> >> - Type format ?
>> >>
>> >> Am I missing something ?
>> >>
>> > Hey,
>> >
>> > So I've made a few changes in the code from the original GraphSON 2.0, 
>> > with the objectives described above, the code is still messy but I just 
>> > thought I'd share some samples to start getting into the work and gather 
>> > some feedback.
>> >
>> > In the example I've created a TinkerGraph with 2 vertices connected by an 
>> > edge. The graph is serialized as a TinkerGraph.
>> > The samples are there : 
>> > https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
>> >
>> > Any feedback appreciated.
>>
>>
>>
>> --
>> Robert Dale
>>



-- 
Robert Dale

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[gallardo.kev...@gmail.com]

On 2016-07-19 18:02 (+0100), Robert Dale  wrote: 
> - It seems redundant to nest a vertex or edge inside a type-value
> object and is inconsistent with a VertexProperty.
> - VertexProperty and (edge) Property are implicit types. I don't know
> if this is ok. Could they ever be used outside of their parents where
> they would need to be typed?

I agree with the VertexProperty remark. That's one last question I wanted to 
solve, if we go for typing Vertex and edges, do we include others? The full 
list I see then is : vertex/edge/vertexproperty/property/graph.

However I am not sure how useful it is to have more than Vertex and Edge. As, 
when deserializing a Vertex for example, there's no question as to what is in 
the "properties" field of the Vertex, there are necessarily only 
VertexProperties. However looking at the API, it seems like it is supported to 
write only a VertexProperty if one wants to (see 
GraphWriter.writeVertexProperty()), so in that case, to me it makes sense to 
add the types for the elements of the list I described above. @stephen any 
thoughts about that ?

> - Edges:
>   - is in/outVLabel new? Couldn't find it in the API or any examples of this.
>   - why not make inV/outV have proper vertices with labels (to satisfy
> the case previous case) instead of just IDs? This would also be more
> consistent with the API.

I haven't touched that part, it was in the format before. I believe this is a 
question for Stephen.

> 
> Otherwise looks good!

Thanks for the feedback.
> 
> On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
>  wrote:
> >
> >
> > On 2016-07-15 16:25 (+0100), 
> > "gallardo.kev...@gmail.com" wrote:
> >>
> >>
> >> On 2016-07-09 16:48 (+0100), Stephen Mallette  wrote:
> >> > With all the work on GLVs and the recent work on GraphSON 2.0, I think 
> >> > it's
> >> > important that we have a solid, efficient, programming language neutral,
> >> > lossless serialization format. Right now that format is GraphSON and it
> >> > works for that purpose (ever more  so with 2.0). Given some discussion on
> >> > the GraphSON 2.0 PR driven a bit by Robert Dale:
> >> >
> >> > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> >> >
> >> > I wonder if we shouldn't consider another IO format that has Gremlin
> >> > Server/GLVs in mind. At this point I'm not suggesting anything specific -
> >> > I'm just hanging the idea out for further discussion and brain storming.
> >> > Thoughts?
> >> >
> >>
> >> Hey, so I'm trying to gather all infos we have here in order to prepare to 
> >> move forward with the implem of GraphSON 2.0, here's what I come up with :
> >>
> >> Things we have :
> >> - Type format.
> >> - The structure in Jackson to implement our own type format.
> >> - All non native Graph types are typed (except the domain specific types).
> >>
> >> New things we need :
> >> - Types for domain specific objects.
> >> - Types for all numeric values.
> >> - Don't serialize empty fields (outV and stuff).
> >>
> >> Things we consider changing :
> >> - Type IDs convention. Before : Java simple class names. Now : starts with 
> >> a "domain" like "gremlin" followed by the "type name", which is a 
> >> lowercased type name (like "uuid", or "float", or "vertex"). Example : 
> >> "gremlin:uuid".
> >> - Type format ?
> >>
> >> Am I missing something ?
> >>
> > Hey,
> >
> > So I've made a few changes in the code from the original GraphSON 2.0, with 
> > the objectives described above, the code is still messy but I just thought 
> > I'd share some samples to start getting into the work and gather some 
> > feedback.
> >
> > In the example I've created a TinkerGraph with 2 vertices connected by an 
> > edge. The graph is serialized as a TinkerGraph.
> > The samples are there : 
> > https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
> >
> > Any feedback appreciated.
> 
> 
> 
> -- 
> Robert Dale
> 

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[gallardo.kev...@gmail.com]

On 2016-07-19 17:47 (+0100), Stephen Mallette  wrote: 
> it should - properties are a Map of Lists of Property values.
> 
> On Tue, Jul 19, 2016 at 12:45 PM, Dylan Millikin 
> wrote:
> 
> > Quick question which is probably handled automatically but is this working
> > with multiple cardinalities on properties?
> >
> > On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com <
> > gallardo.kev...@gmail.com> wrote:
> >
> > >
> > >
> > > On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com"<
> > > gallardo.kev...@gmail.com> wrote:
> > > >
> > > >
> > > > On 2016-07-09 16:48 (+0100), Stephen Mallette 
> > > wrote:
> > > > > With all the work on GLVs and the recent work on GraphSON 2.0, I
> > think
> > > it's
> > > > > important that we have a solid, efficient, programming language
> > > neutral,
> > > > > lossless serialization format. Right now that format is GraphSON and
> > it
> > > > > works for that purpose (ever more  so with 2.0). Given some
> > discussion
> > > on
> > > > > the GraphSON 2.0 PR driven a bit by Robert Dale:
> > > > >
> > > > > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> > > > >
> > > > > I wonder if we shouldn't consider another IO format that has Gremlin
> > > > > Server/GLVs in mind. At this point I'm not suggesting anything
> > > specific -
> > > > > I'm just hanging the idea out for further discussion and brain
> > > storming.
> > > > > Thoughts?
> > > > >
> > > >
> > > > Hey, so I'm trying to gather all infos we have here in order to prepare
> > > to move forward with the implem of GraphSON 2.0, here's what I come up
> > with
> > > :
> > > >
> > > > Things we have :
> > > > - Type format.
> > > > - The structure in Jackson to implement our own type format.
> > > > - All non native Graph types are typed (except the domain specific
> > > types).
> > > >
> > > > New things we need :
> > > > - Types for domain specific objects.
> > > > - Types for all numeric values.
> > > > - Don't serialize empty fields (outV and stuff).
> > > >
> > > > Things we consider changing :
> > > > - Type IDs convention. Before : Java simple class names. Now : starts
> > > with a "domain" like "gremlin" followed by the "type name", which is a
> > > lowercased type name (like "uuid", or "float", or "vertex"). Example :
> > > "gremlin:uuid".
> > > > - Type format ?
> > > >
> > > > Am I missing something ?
> > > >
> > > Hey,
> > >
> > > So I've made a few changes in the code from the original GraphSON 2.0,
> > > with the objectives described above, the code is still messy but I just
> > > thought I'd share some samples to start getting into the work and gather
> > > some feedback.
> > >
> > > In the example I've created a TinkerGraph with 2 vertices connected by an
> > > edge. The graph is serialized as a TinkerGraph.
> > > The samples are there :
> > > https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
> > >
> > > Any feedback appreciated.
> > >
> >
> 
I confirm, I didn't change anything in that section.

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Robert Dale]

- It seems redundant to nest a vertex or edge inside a type-value
object and is inconsistent with a VertexProperty.
- VertexProperty and (edge) Property are implicit types. I don't know
if this is ok. Could they ever be used outside of their parents where
they would need to be typed?
- Edges:
  - is in/outVLabel new? Couldn't find it in the API or any examples of this.
  - why not make inV/outV have proper vertices with labels (to satisfy
the case previous case) instead of just IDs? This would also be more
consistent with the API.

Otherwise looks good!

On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
 wrote:
>
>
> On 2016-07-15 16:25 (+0100), 
> "gallardo.kev...@gmail.com" wrote:
>>
>>
>> On 2016-07-09 16:48 (+0100), Stephen Mallette  wrote:
>> > With all the work on GLVs and the recent work on GraphSON 2.0, I think it's
>> > important that we have a solid, efficient, programming language neutral,
>> > lossless serialization format. Right now that format is GraphSON and it
>> > works for that purpose (ever more  so with 2.0). Given some discussion on
>> > the GraphSON 2.0 PR driven a bit by Robert Dale:
>> >
>> > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
>> >
>> > I wonder if we shouldn't consider another IO format that has Gremlin
>> > Server/GLVs in mind. At this point I'm not suggesting anything specific -
>> > I'm just hanging the idea out for further discussion and brain storming.
>> > Thoughts?
>> >
>>
>> Hey, so I'm trying to gather all infos we have here in order to prepare to 
>> move forward with the implem of GraphSON 2.0, here's what I come up with :
>>
>> Things we have :
>> - Type format.
>> - The structure in Jackson to implement our own type format.
>> - All non native Graph types are typed (except the domain specific types).
>>
>> New things we need :
>> - Types for domain specific objects.
>> - Types for all numeric values.
>> - Don't serialize empty fields (outV and stuff).
>>
>> Things we consider changing :
>> - Type IDs convention. Before : Java simple class names. Now : starts with a 
>> "domain" like "gremlin" followed by the "type name", which is a lowercased 
>> type name (like "uuid", or "float", or "vertex"). Example : "gremlin:uuid".
>> - Type format ?
>>
>> Am I missing something ?
>>
> Hey,
>
> So I've made a few changes in the code from the original GraphSON 2.0, with 
> the objectives described above, the code is still messy but I just thought 
> I'd share some samples to start getting into the work and gather some 
> feedback.
>
> In the example I've created a TinkerGraph with 2 vertices connected by an 
> edge. The graph is serialized as a TinkerGraph.
> The samples are there : 
> https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
>
> Any feedback appreciated.



-- 
Robert Dale

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Stephen Mallette]

it should - properties are a Map of Lists of Property values.

On Tue, Jul 19, 2016 at 12:45 PM, Dylan Millikin 
wrote:

> Quick question which is probably handled automatically but is this working
> with multiple cardinalities on properties?
>
> On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com <
> gallardo.kev...@gmail.com> wrote:
>
> >
> >
> > On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com"<
> > gallardo.kev...@gmail.com> wrote:
> > >
> > >
> > > On 2016-07-09 16:48 (+0100), Stephen Mallette 
> > wrote:
> > > > With all the work on GLVs and the recent work on GraphSON 2.0, I
> think
> > it's
> > > > important that we have a solid, efficient, programming language
> > neutral,
> > > > lossless serialization format. Right now that format is GraphSON and
> it
> > > > works for that purpose (ever more  so with 2.0). Given some
> discussion
> > on
> > > > the GraphSON 2.0 PR driven a bit by Robert Dale:
> > > >
> > > > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> > > >
> > > > I wonder if we shouldn't consider another IO format that has Gremlin
> > > > Server/GLVs in mind. At this point I'm not suggesting anything
> > specific -
> > > > I'm just hanging the idea out for further discussion and brain
> > storming.
> > > > Thoughts?
> > > >
> > >
> > > Hey, so I'm trying to gather all infos we have here in order to prepare
> > to move forward with the implem of GraphSON 2.0, here's what I come up
> with
> > :
> > >
> > > Things we have :
> > > - Type format.
> > > - The structure in Jackson to implement our own type format.
> > > - All non native Graph types are typed (except the domain specific
> > types).
> > >
> > > New things we need :
> > > - Types for domain specific objects.
> > > - Types for all numeric values.
> > > - Don't serialize empty fields (outV and stuff).
> > >
> > > Things we consider changing :
> > > - Type IDs convention. Before : Java simple class names. Now : starts
> > with a "domain" like "gremlin" followed by the "type name", which is a
> > lowercased type name (like "uuid", or "float", or "vertex"). Example :
> > "gremlin:uuid".
> > > - Type format ?
> > >
> > > Am I missing something ?
> > >
> > Hey,
> >
> > So I've made a few changes in the code from the original GraphSON 2.0,
> > with the objectives described above, the code is still messy but I just
> > thought I'd share some samples to start getting into the work and gather
> > some feedback.
> >
> > In the example I've created a TinkerGraph with 2 vertices connected by an
> > edge. The graph is serialized as a TinkerGraph.
> > The samples are there :
> > https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
> >
> > Any feedback appreciated.
> >
>

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Dylan Millikin]

Quick question which is probably handled automatically but is this working
with multiple cardinalities on properties?

On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com <
gallardo.kev...@gmail.com> wrote:

>
>
> On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com"<
> gallardo.kev...@gmail.com> wrote:
> >
> >
> > On 2016-07-09 16:48 (+0100), Stephen Mallette 
> wrote:
> > > With all the work on GLVs and the recent work on GraphSON 2.0, I think
> it's
> > > important that we have a solid, efficient, programming language
> neutral,
> > > lossless serialization format. Right now that format is GraphSON and it
> > > works for that purpose (ever more  so with 2.0). Given some discussion
> on
> > > the GraphSON 2.0 PR driven a bit by Robert Dale:
> > >
> > > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> > >
> > > I wonder if we shouldn't consider another IO format that has Gremlin
> > > Server/GLVs in mind. At this point I'm not suggesting anything
> specific -
> > > I'm just hanging the idea out for further discussion and brain
> storming.
> > > Thoughts?
> > >
> >
> > Hey, so I'm trying to gather all infos we have here in order to prepare
> to move forward with the implem of GraphSON 2.0, here's what I come up with
> :
> >
> > Things we have :
> > - Type format.
> > - The structure in Jackson to implement our own type format.
> > - All non native Graph types are typed (except the domain specific
> types).
> >
> > New things we need :
> > - Types for domain specific objects.
> > - Types for all numeric values.
> > - Don't serialize empty fields (outV and stuff).
> >
> > Things we consider changing :
> > - Type IDs convention. Before : Java simple class names. Now : starts
> with a "domain" like "gremlin" followed by the "type name", which is a
> lowercased type name (like "uuid", or "float", or "vertex"). Example :
> "gremlin:uuid".
> > - Type format ?
> >
> > Am I missing something ?
> >
> Hey,
>
> So I've made a few changes in the code from the original GraphSON 2.0,
> with the objectives described above, the code is still messy but I just
> thought I'd share some samples to start getting into the work and gather
> some feedback.
>
> In the example I've created a TinkerGraph with 2 vertices connected by an
> edge. The graph is serialized as a TinkerGraph.
> The samples are there :
> https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
>
> Any feedback appreciated.
>

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[gallardo.kev...@gmail.com]

On 2016-07-15 16:25 (+0100), 
"gallardo.kev...@gmail.com" wrote: 
> 
> 
> On 2016-07-09 16:48 (+0100), Stephen Mallette  wrote: 
> > With all the work on GLVs and the recent work on GraphSON 2.0, I think it's
> > important that we have a solid, efficient, programming language neutral,
> > lossless serialization format. Right now that format is GraphSON and it
> > works for that purpose (ever more  so with 2.0). Given some discussion on
> > the GraphSON 2.0 PR driven a bit by Robert Dale:
> > 
> > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> > 
> > I wonder if we shouldn't consider another IO format that has Gremlin
> > Server/GLVs in mind. At this point I'm not suggesting anything specific -
> > I'm just hanging the idea out for further discussion and brain storming.
> > Thoughts?
> > 
> 
> Hey, so I'm trying to gather all infos we have here in order to prepare to 
> move forward with the implem of GraphSON 2.0, here's what I come up with : 
> 
> Things we have : 
> - Type format.
> - The structure in Jackson to implement our own type format.
> - All non native Graph types are typed (except the domain specific types).
> 
> New things we need : 
> - Types for domain specific objects.
> - Types for all numeric values.
> - Don't serialize empty fields (outV and stuff).
> 
> Things we consider changing :
> - Type IDs convention. Before : Java simple class names. Now : starts with a 
> "domain" like "gremlin" followed by the "type name", which is a lowercased 
> type name (like "uuid", or "float", or "vertex"). Example : "gremlin:uuid".
> - Type format ?
> 
> Am I missing something ?
> 
Hey,

So I've made a few changes in the code from the original GraphSON 2.0, with the 
objectives described above, the code is still messy but I just thought I'd 
share some samples to start getting into the work and gather some feedback.

In the example I've created a TinkerGraph with 2 vertices connected by an edge. 
The graph is serialized as a TinkerGraph.
The samples are there : 
https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60

Any feedback appreciated.

Re: [DISCUSS] 3.1.x code line

[Stephen Mallette]

That's typically how we do things here at TinkerPop - we tend to allow
"features that don't break public API" into the "z" of "x.y.z", however,
we're trying to wind down development on the 3.1.x line of code and not
introduce too much more there. I'd be open to a new bits of documentation
on that line if it is applicable to 3.1.x, but I guess it would depend on
what that documentation was. I think that if someone thinks something
should go in 3.1.x at this point they can just do a DISCUSS thread here on
dev and look to build some consensus.

I think that EOL of 3.1.x was what this email was about. We plan to
continue to fix things there and maintain it for the foreseeable future.
3.2.x will also continue for the foreseeable future. Next body of releases
haven't been discussed I don't think. I'm just throwing ideas out there,
but I would think that 3.2.2 (and 3.1.4 i suppose if there's anything to
release) would come as soon as gremlin-python is settled - maybe end of
summer? Then 3.3.x (and 3.2.3/3.1.5???) by end of year?  we seem to be in a
general pattern of releasing something every couple of months or so, so i'm
largely basing my thoughts on that at this point.





On Tue, Jul 19, 2016 at 11:09 AM, Robert Dale  wrote:

> Stephen, I noticed a couple of issues moved out of 3.1.4 for reason of
> bug fixes only. Typically the semantic versioning is limited to
> "public API". So I would argue that adding a service script (optional
> usage at that) and a tutorial (documentation) would not affect the
> public API or even general behavior of any of the components. Of
> course, how you interpret and apply semantic versioning is entirely up
> to you.
>
> Are there any plans or thoughts on a support roadmap (when 3.1, 3.2
> are EOL) and future release roadmap, timelines?
>
>
> On Tue, Jul 19, 2016 at 10:49 AM, Stephen Mallette 
> wrote:
> > It sounds like we have general consensus on going with 3.1.x for bug
> fixes
> > only. I've updated JIRA as such and moved issues around. I will mention
> > that while i was going through the release work for 3.1.3/3.2.1 I
> realized
> > that the minor exception to this rule of "bug fixes only" on the 3.1.x
> line
> > would be changes to the release process which I would hope we could keep
> as
> > similar as possible for as long as possible. I'd hate to have different
> > scripts/instructions for one version as opposed to another - that will
> not
> > make the job of release manager nice.
> >
> > Thanks,
> >
> > Stephen
> >
> >
> > On Mon, Jul 18, 2016 at 9:02 PM, Dylan Millikin <
> dylan.milli...@gmail.com>
> > wrote:
> >
> >> +1 from me as well. Sounds good.
> >>
> >> On Thu, Jul 14, 2016 at 2:14 PM, Ted Wilmes  wrote:
> >>
> >> > It does for me too, +1.
> >> >
> >> > --Ted
> >> >
> >> > On Wed, Jul 13, 2016 at 3:44 PM, Hadrian Zbarcea 
> >> > wrote:
> >> >
> >> > > +1. It does to me.
> >> > > Hadrian
> >> > >
> >> > >
> >> > > On 07/13/2016 04:29 PM, Stephen Mallette wrote:
> >> > >
> >> > >> Since we don't really follow semantic versioning for releases, I
> >> thought
> >> > >> we
> >> > >> should discuss the 3.1.x code line. We've been steadily adding
> >> features
> >> > >> right up to our current 3.1.3 release which we will vote on
> shortly. I
> >> > >> think it's pretty awesome that we've managed to maintain that older
> >> line
> >> > >> of
> >> > >> code for as long as we have and I think we've evolved it in a very
> >> > >> sensible
> >> > >> way.
> >> > >>
> >> > >> I think we should continue to maintain 3.1.x after the 3.1.3
> release,
> >> > >> which
> >> > >> would mean a 3.1.4 release at some point, but we should strictly
> limit
> >> > the
> >> > >> changes there to bug fixes and not do any "new features" on that
> line
> >> of
> >> > >> code (i.e the tp31 branch). As it stands, I don't see any open
> "bugs"
> >> > for
> >> > >> the 3.1.3 in JIRA so as of right now, we wouldn't have much planned
> >> for
> >> > >> 3.1.4.
> >> > >>
> >> > >> Does that make sense for everyone?
> >> > >>
> >> > >>
> >> >
> >>
>
>
>
> --
> Robert Dale
>

Re: [DISCUSS] 3.1.x code line

[Robert Dale]

Stephen, I noticed a couple of issues moved out of 3.1.4 for reason of
bug fixes only. Typically the semantic versioning is limited to
"public API". So I would argue that adding a service script (optional
usage at that) and a tutorial (documentation) would not affect the
public API or even general behavior of any of the components. Of
course, how you interpret and apply semantic versioning is entirely up
to you.

Are there any plans or thoughts on a support roadmap (when 3.1, 3.2
are EOL) and future release roadmap, timelines?


On Tue, Jul 19, 2016 at 10:49 AM, Stephen Mallette  wrote:
> It sounds like we have general consensus on going with 3.1.x for bug fixes
> only. I've updated JIRA as such and moved issues around. I will mention
> that while i was going through the release work for 3.1.3/3.2.1 I realized
> that the minor exception to this rule of "bug fixes only" on the 3.1.x line
> would be changes to the release process which I would hope we could keep as
> similar as possible for as long as possible. I'd hate to have different
> scripts/instructions for one version as opposed to another - that will not
> make the job of release manager nice.
>
> Thanks,
>
> Stephen
>
>
> On Mon, Jul 18, 2016 at 9:02 PM, Dylan Millikin 
> wrote:
>
>> +1 from me as well. Sounds good.
>>
>> On Thu, Jul 14, 2016 at 2:14 PM, Ted Wilmes  wrote:
>>
>> > It does for me too, +1.
>> >
>> > --Ted
>> >
>> > On Wed, Jul 13, 2016 at 3:44 PM, Hadrian Zbarcea 
>> > wrote:
>> >
>> > > +1. It does to me.
>> > > Hadrian
>> > >
>> > >
>> > > On 07/13/2016 04:29 PM, Stephen Mallette wrote:
>> > >
>> > >> Since we don't really follow semantic versioning for releases, I
>> thought
>> > >> we
>> > >> should discuss the 3.1.x code line. We've been steadily adding
>> features
>> > >> right up to our current 3.1.3 release which we will vote on shortly. I
>> > >> think it's pretty awesome that we've managed to maintain that older
>> line
>> > >> of
>> > >> code for as long as we have and I think we've evolved it in a very
>> > >> sensible
>> > >> way.
>> > >>
>> > >> I think we should continue to maintain 3.1.x after the 3.1.3 release,
>> > >> which
>> > >> would mean a 3.1.4 release at some point, but we should strictly limit
>> > the
>> > >> changes there to bug fixes and not do any "new features" on that line
>> of
>> > >> code (i.e the tp31 branch). As it stands, I don't see any open "bugs"
>> > for
>> > >> the 3.1.3 in JIRA so as of right now, we wouldn't have much planned
>> for
>> > >> 3.1.4.
>> > >>
>> > >> Does that make sense for everyone?
>> > >>
>> > >>
>> >
>>



-- 
Robert Dale

[jira] [Updated] (TINKERPOP-980) Add a service script or daemon mode in the distribution

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-980:
---
Fix Version/s: (was: 3.1.4)

Release 3.1.4 is for bugs only at this point as per discussion on the mailing 
list. 

> Add a service script or daemon mode in the distribution
> ---
>
> Key: TINKERPOP-980
> URL: https://issues.apache.org/jira/browse/TINKERPOP-980
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Jeremy Hanna
>Assignee: Dylan Millikin
>Priority: Minor
>
> Based on this discussion, it looks like there was an example from [~dkuppitz] 
> on how to create a gremlin server service on linux:
> https://groups.google.com/forum/#!msg/gremlin-users/uA48IQ3YJcw/4KnUKIS8HI4J
> Here is a link to the gist for the service:
> https://gist.github.com/dkuppitz/20bda51e3465a612cd9b
> I think it would be great to include this or a way to daemonize the server 
> into the tinkerpop distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1342) Allow setting scriptEvaluationTimeout in driver

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1342:

Fix Version/s: (was: 3.1.4)
   3.2.2

Release 3.1.4 is for bugs only at this point as per discussion on the mailing 
list.

> Allow setting scriptEvaluationTimeout in driver
> ---
>
> Key: TINKERPOP-1342
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1342
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.2
>
>
> Allow this setting to be applied in the driver somehow so as to give the user 
> the ability to override the server setting in the request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1007) Gremlin at the Movies Tutorial (SQL-Style in Gremlin)

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1007:

Fix Version/s: (was: 3.1.4)

Release 3.1.4 is for bugs only at this point as per discussion on the mailing 
list.

> Gremlin at the Movies Tutorial (SQL-Style in Gremlin)
> -
>
> Key: TINKERPOP-1007
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1007
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Jeremy Hanna
>
> We need more tutorials. [~spmallette]'s "Getting Started" tutorial is great, 
> but  (as acknowledged by Russell Jurney) we now need to meet the needs of 
> intermediate users as well.
> I think we should do another "30 Minute" tutorial called "Gremlin at the 
> Movies" and use the MovieLens dataset. 
> http://grouplens.org/datasets/movielens/ (seems we can legally do this -- 
> http://files.grouplens.org/datasets/movielens/ml-1m-README.txt).
> In this tutorial we provide a {{gryo}} file and the user will learn:
> * Reducing barriers like {{count}}, {{max}}, {{sum}}, etc.
> * {{select}} and its use with {{by}}-projections.
> * {{match}} and its use with {{where}}, {{select}}, etc.
> I think we present the queries in a very "SQL fashion" so people see that 
> Gremlin can be written using the popular/known SQL constructs of select, 
> where, group, by, etc.
> Thus, "graph data" but "table feel."
> Get information from:
> http://www.slideshare.net/slidarko/the-gremlin-traversal-language?related=1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Code Freeze 3.1.3/3.2.1

[Stephen Mallette]

I've set up version 3.1.4 and 3.2.2 in JIRA and migrated all old issues in
those lines to them. As per previous discussion about the 3.1.x line, I'll
be moving out all issues that aren't bug or release related which should
just leave:

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

Also, I noticed an issue with some JIRA issues we had out there - if you
close an issue as "not a problem" or is "not reproducible" or the like, I
think that we shouldn't clear the "Fix version" because otherwise those
items will show up in the CHANGELOG and i don't think that the CHANGELOG
should have "invalid" issues listed in it.

The release branches will remain frozen during our vote period. I'll post
back here when everything is opened back up again.

Thanks,

Stephen


On Mon, Jul 18, 2016 at 4:36 PM, Stephen Mallette 
wrote:

> Here's the revised validate-distribution.sh file:
>
> https://gist.github.com/spmallette/8a1296a50320fe0e1b350fc6caef372e
>
> Please use that to test out the release (if you use that approach - it
> really is a super easy way to checkout the distribution if you'd like to
> participate in the vote and don't have a ton of time to look at everything
> manually).  I'll commit these changes to the repo after release is all
> settled.
>
> On Mon, Jul 18, 2016 at 4:00 PM, Stephen Mallette 
> wrote:
>
>> Having some trouble with release. Some of the trouble is a bit out of my
>> control - like a bank of thunderstorms flickering my internet connection.
>> Some of the trouble was self-created, like trying to rename the
>> distributions - which I've abandoned doing for this release (we'll do it
>> for the next one now that I see all the problems with doing that). And now
>> i'm stuck with validate-distribution.sh which doesn't seem to want to
>> behave. I think I have it figured out now with a patch or two. I'll post
>> that as a gist later for everyone to use as a replacement for the one in
>> git or perhaps make the commit to master before i start working on 3.2.1 -
>> I don't plan to go back through the release process for 3.1.3 to make
>> another commit on tp31 at this point. Anyway, as soon as this
>> validate-distribution.sh run finishes successfully, you can expect a VOTE
>> thread for 3.1.3.
>>
>> If I can get 3.2.1 out as well tonight I will but it might be better for
>> me to wait until morning because I don't want to make any dumb mistakes at
>> this point and it's always good to have a sharp mind when doing this stuff.
>> So, worst case, the 3.2.1 VOTE should start tomorrow morning. Sorry for the
>> delay
>>
>> Thanks,
>>
>> Stephen
>>
>>
>>
>> On Sat, Jul 16, 2016 at 8:57 AM, Marko Rodriguez 
>> wrote:
>>
>>> Thanks again for handling the release process.
>>>
>>> I appreciate nearly nothing in this world except for the effort you put
>>> into the release process.
>>>
>>> Thank you,
>>> Marko.
>>>
>>> http://markorodriguez.com
>>>
>>>
>>>
>>> > On Jul 15, 2016, at 4:39 PM, Stephen Mallette 
>>> wrote:
>>> >
>>> > Everything looks good to do a vote for 3.1.3 and 3.1.2 on Monday. I'm
>>> going
>>> > to publish the final SNAPSHOT docs over the weekend - nothing has
>>> changed
>>> > of significance for the artifacts SNAPSHOTS to warrant republishing.
>>> >
>>> > On Wed, Jul 13, 2016 at 7:08 AM, Stephen Mallette <
>>> spmalle...@gmail.com>
>>> > wrote:
>>> >
>>> >> I've run full integration tests on tp31 and master and both passed.
>>> As a
>>> >> result, I've published 3.2.1-SNAPSHOT and 3.1.3-SNAPSHOT to the Apache
>>> >> Snapshots repo. I hope developers of graph databases, drivers, etc.
>>> can get
>>> >> a moment to try it out and report any problems.
>>> >>
>>> >>
>>> >> On Tue, Jul 12, 2016 at 9:52 AM, Marko Rodriguez <
>>> okramma...@gmail.com>
>>> >> wrote:
>>> >>
>>> >>> Hello,
>>> >>>
>>>  Code freeze essentially begins today. We cleared up all the
>>> remaining
>>>  issues that were lingering. Please focus on testing and
>>> documentation
>>> >>> for
>>>  the next few days with a vote for release on Monday July 18th 2016.
>>> >>>
>>> >>>
>>> >>> Thank you Stephen.
>>> >>>
>>> >>> As I was saying in HipChat, while we have merged the
>>> >>> PathRetractionStrategy work (
>>> >>> https://issues.apache.org/jira/browse/TINKERPOP-1254 <
>>> >>> https://issues.apache.org/jira/browse/TINKERPOP-1254>), I’m
>>> continually
>>> >>> benchmarking and testing scenarios and am finding numerous little
>>> nick nack
>>> >>> bugs and obvious optimizations. I’m going to continue to CTR to
>>> master/
>>> >>> these updates and note that each evening I’m doing local integration
>>> >>> testing to ensure that no one finds a hiccup (if any) that were
>>> caused by
>>> >>> this “nick nack” work I’m doing.
>>> >>>
>>> >>> Again, thank you Stephen for managing the release process (as
>>> always).
>>> >>>
>>> >>> Marko.
>>> >>>
>>> >>> http://markorodriguez.com
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>
>

[VOTE] TinkerPop 3.2.1 Release

[Stephen Mallette]

Hello,

We are happy to announce that TinkerPop 3.2.1 is ready for release - note
the lack of "-incubating" everywhere.  :)

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

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

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

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

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.2.1/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.2.1/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.2.1/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.2.1/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=c5a9e2815e76f044e6b33b773b6bb0bb048270cc

The release notes are available here:
https://github.com/apache/tinkerpop/blob/3.2.1/CHANGELOG.asciidoc#release-3-2-1

The [VOTE] will be open for the next 72 hours --- closing Friday (July 22,
2016) at 9:30 am EST.

My vote is +1.

Thank you very much,
Stephen

[jira] [Updated] (TINKERPOP-1358) spark-gremlin tests require special setup

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1358:

Fix Version/s: (was: 3.2.1)

> spark-gremlin tests require special setup
> -
>
> Key: TINKERPOP-1358
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1358
> Project: TinkerPop
>  Issue Type: Test
>  Components: hadoop
>Affects Versions: 3.2.0-incubating
> Environment: Linux
> No spark, hadoop installed, configured, or running.
> No spark, hadoop env vars set.
>Reporter: Robert Dale
>Assignee: Marko A. Rodriguez
> Attachments: console.txt
>
>
> cd spark-gremlin; mvn clean install
> Most tests fail with:
> java.net.BindException: Cannot assign requested address: Service 
> 'sparkDriver' failed after 16 retries!
>  Eventually leads to resource starvation: OutOfMemoryError: unable to create 
> new native thread. Presumably because exceptions are not caught and 
> SparkContexts closed.
> If tests require external server, perhaps they would be best served as 
> integration tests.  Otherwise, there's some undocumented special sauce 
> missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1358) spark-gremlin tests require special setup

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1358.
---
Resolution: Not A Problem

> spark-gremlin tests require special setup
> -
>
> Key: TINKERPOP-1358
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1358
> Project: TinkerPop
>  Issue Type: Test
>  Components: hadoop
>Affects Versions: 3.2.0-incubating
> Environment: Linux
> No spark, hadoop installed, configured, or running.
> No spark, hadoop env vars set.
>Reporter: Robert Dale
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
> Attachments: console.txt
>
>
> cd spark-gremlin; mvn clean install
> Most tests fail with:
> java.net.BindException: Cannot assign requested address: Service 
> 'sparkDriver' failed after 16 retries!
>  Eventually leads to resource starvation: OutOfMemoryError: unable to create 
> new native thread. Presumably because exceptions are not caught and 
> SparkContexts closed.
> If tests require external server, perhaps they would be best served as 
> integration tests.  Otherwise, there's some undocumented special sauce 
> missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1358) spark-gremlin tests require special setup

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1358.
---
Resolution: Not A Problem

> spark-gremlin tests require special setup
> -
>
> Key: TINKERPOP-1358
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1358
> Project: TinkerPop
>  Issue Type: Test
>  Components: hadoop
>Affects Versions: 3.2.0-incubating
> Environment: Linux
> No spark, hadoop installed, configured, or running.
> No spark, hadoop env vars set.
>Reporter: Robert Dale
>Assignee: Marko A. Rodriguez
> Attachments: console.txt
>
>
> cd spark-gremlin; mvn clean install
> Most tests fail with:
> java.net.BindException: Cannot assign requested address: Service 
> 'sparkDriver' failed after 16 retries!
>  Eventually leads to resource starvation: OutOfMemoryError: unable to create 
> new native thread. Presumably because exceptions are not caught and 
> SparkContexts closed.
> If tests require external server, perhaps they would be best served as 
> integration tests.  Otherwise, there's some undocumented special sauce 
> missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (TINKERPOP-1358) spark-gremlin tests require special setup

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1358:
-

> spark-gremlin tests require special setup
> -
>
> Key: TINKERPOP-1358
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1358
> Project: TinkerPop
>  Issue Type: Test
>  Components: hadoop
>Affects Versions: 3.2.0-incubating
> Environment: Linux
> No spark, hadoop installed, configured, or running.
> No spark, hadoop env vars set.
>Reporter: Robert Dale
>Assignee: Marko A. Rodriguez
> Attachments: console.txt
>
>
> cd spark-gremlin; mvn clean install
> Most tests fail with:
> java.net.BindException: Cannot assign requested address: Service 
> 'sparkDriver' failed after 16 retries!
>  Eventually leads to resource starvation: OutOfMemoryError: unable to create 
> new native thread. Presumably because exceptions are not caught and 
> SparkContexts closed.
> If tests require external server, perhaps they would be best served as 
> integration tests.  Otherwise, there's some undocumented special sauce 
> missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (TINKERPOP-1358) spark-gremlin tests require special setup

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1358:
-

> spark-gremlin tests require special setup
> -
>
> Key: TINKERPOP-1358
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1358
> Project: TinkerPop
>  Issue Type: Test
>  Components: hadoop
>Affects Versions: 3.2.0-incubating
> Environment: Linux
> No spark, hadoop installed, configured, or running.
> No spark, hadoop env vars set.
>Reporter: Robert Dale
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
> Attachments: console.txt
>
>
> cd spark-gremlin; mvn clean install
> Most tests fail with:
> java.net.BindException: Cannot assign requested address: Service 
> 'sparkDriver' failed after 16 retries!
>  Eventually leads to resource starvation: OutOfMemoryError: unable to create 
> new native thread. Presumably because exceptions are not caught and 
> SparkContexts closed.
> If tests require external server, perhaps they would be best served as 
> integration tests.  Otherwise, there's some undocumented special sauce 
> missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1358) spark-gremlin tests require special setup

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1358:

Labels:   (was: spark)

> spark-gremlin tests require special setup
> -
>
> Key: TINKERPOP-1358
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1358
> Project: TinkerPop
>  Issue Type: Test
>  Components: hadoop
>Affects Versions: 3.2.0-incubating
> Environment: Linux
> No spark, hadoop installed, configured, or running.
> No spark, hadoop env vars set.
>Reporter: Robert Dale
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.1
>
> Attachments: console.txt
>
>
> cd spark-gremlin; mvn clean install
> Most tests fail with:
> java.net.BindException: Cannot assign requested address: Service 
> 'sparkDriver' failed after 16 retries!
>  Eventually leads to resource starvation: OutOfMemoryError: unable to create 
> new native thread. Presumably because exceptions are not caught and 
> SparkContexts closed.
> If tests require external server, perhaps they would be best served as 
> integration tests.  Otherwise, there's some undocumented special sauce 
> missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)