[GitHub] tinkerpop pull request #711: TINKERPOP-1746: Better error message on wrong o...

2017-09-12 Thread dkuppitz 
Github user dkuppitz commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/711#discussion_r138436841
  
--- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/RepeatStep.java
 ---
@@ -91,6 +91,8 @@ public void setEmitTraversal(final Traversal.Admin 
emitTraversal) {
 }
 
 public Traversal.Admin getRepeatTraversal() {
+if(null == this.repeatTraversal)
+throw new IllegalStateException("The repeat()-traversal was 
not defined: " + this);
--- End diff --

I wouldn't throw an exception in a Getter.


---

[GitHub] tinkerpop issue #708: TINKERPOP-1770 Enable timeouts for remote traversals

2017-09-12 Thread okram 
Github user okram commented on the issue:

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


---

[jira] [Commented] (TINKERPOP-1781) Traversal admin addStep does not update bytecode

2017-09-12 Thread Marko A. Rodriguez (JIRA) 

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

Marko A. Rodriguez commented on TINKERPOP-1781:
---

There is no good general solution to this problem given that compilation will 
yield steps that don't have a correlate bytecode representation. For instance, 
{{ProviderOptimizationStrategy}} compilation stage. 

> Traversal admin addStep does not update bytecode
> 
>
> Key: TINKERPOP-1781
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1781
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Ted Wilmes
>
> Right now bytecode is constructed at traversal construction time and is not 
> updated post-construction when traversal rewriting happens via strategies. 
> This works fine in most cases because the traversal is locked post-strategy 
> application and will be executed, not serialized out for execution somewhere 
> else. 
> There are issues when trying to apply client side, pre-serialization 
> traversal rewriting (a kind of client-side traversal strategy outside of the 
> usual strategy flow). Since a direct call to {{addStep}} circumvents the 
> bytecode construction, the bytecode diverges from the rewritten traversal.
> {code}
> gremlin> traversal = g.V().out();null
> ==>null
> gremlin> traversal.getSteps()
> ==>GraphStep(vertex,[])
> ==>VertexStep(OUT,vertex)
> gremlin> traversal.getBytecode()
> ==>[[], [V(), out()]]
> gremlin> TraversalHelper.insertAfterStep(new CountGlobalStep(traversal), 
> traversal.getSteps()[1], traversal.asAdmin())
> ==>null
> gremlin> traversal.getSteps()
> ==>GraphStep(vertex,[])
> ==>VertexStep(OUT,vertex)
> ==>CountGlobalStep
> gremlin> traversal.getBytecode()
> ==>[[], [V(), out()]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TINKERPOP-1781) Traversal admin addStep does not update bytecode

2017-09-12 Thread Ted Wilmes (JIRA) 
Ted Wilmes created TINKERPOP-1781:
-

 Summary: Traversal admin addStep does not update bytecode
 Key: TINKERPOP-1781
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1781
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.6, 3.3.0
Reporter: Ted Wilmes


Right now bytecode is constructed at traversal construction time and is not 
updated post-construction when traversal rewriting happens via strategies. This 
works fine in most cases because the traversal is locked post-strategy 
application and will be executed, not serialized out for execution somewhere 
else. 

There are issues when trying to apply client side, pre-serialization traversal 
rewriting (a kind of client-side traversal strategy outside of the usual 
strategy flow). Since a direct call to {{addStep}} circumvents the bytecode 
construction, the bytecode diverges from the rewritten traversal.

{code}
gremlin> traversal = g.V().out();null
==>null
gremlin> traversal.getSteps()
==>GraphStep(vertex,[])
==>VertexStep(OUT,vertex)
gremlin> traversal.getBytecode()
==>[[], [V(), out()]]
gremlin> TraversalHelper.insertAfterStep(new CountGlobalStep(traversal), 
traversal.getSteps()[1], traversal.asAdmin())
==>null
gremlin> traversal.getSteps()
==>GraphStep(vertex,[])
==>VertexStep(OUT,vertex)
==>CountGlobalStep
gremlin> traversal.getBytecode()
==>[[], [V(), out()]]
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

2017-09-12 Thread ASF GitHub Bot (JIRA) 

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

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

GitHub user FlorianHockmann opened a pull request:

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

TINKERPOP-1752: Gremlin.Net: Generate completely type-safe methods

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

All steps are now (basically) type-safe and the original argument names 
from Gremlin-Java are used. However, we currently don't support some Java types 
like `Comparator`. Those were simply replaced by `object` until we find a 
better solution. A problem with this workaround is that some overloads from 
Gremlin-Java are not supported in Gremlin.Net as they would result in the same 
method signature.

The implementation of `Bindings` is now basically the same as in 
Gremlin-Java. This change was necessary as `Bindings.Of()` can no longer return 
a `Binding` object

These changes also revealed a bug in the tests where the 
`WithoutStrategies` source step was called with objects of strategies instead 
of just with their types. However, `WithoutStrategies` still can't work right 
now as a GraphSON serializer is missing for `Type`.

The `Group` step for example looks now like this:
```cs
/// 
/// Adds the group step to this .
/// 
public GraphTraversal< S , IDictionary > Group ()
{
Bytecode.AddStep("group");
return Wrap< S , IDictionary >(this);
}

/// 
/// Adds the group step to this .
/// 
public GraphTraversal< S , E > Group (string sideEffectKey)
{
Bytecode.AddStep("group", sideEffectKey);
return Wrap< S , E >(this);
}
```
So this should also solve 
[TINKERPOP-1751](https://issues.apache.org/jira/browse/TINKERPOP-1751) that 
mentioned the missing overload for `Group` that returns `IDictionary`.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1752

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/712.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #712


commit 05851764f1e20abb1a82b7d662b4681d602a5774
Author: Florian Hockmann 
Date:   2017-08-17T20:57:07Z

Make Gremlin.Net graph traversal API type-safe

All steps are now type-safe and the original argument names from
Gremlin-Java are used. However, we currently don't support some Java
types like Comparator. Those were simply replaced by object until we
find a better solution. A problem of this workaround is that some
overloads from Gremlin-Java are not supported in Gremlin.Net as they
would result in the same method signature.
This required to change how Bindings work as Bindings.Of() can no longer
return a Binding object. The implementation for Bindings is now
basically the same as in Gremlin-Java.

This also revealed a bug in the tests that called the WithoutStrategies 
source step with objects of strategies instead of just with their types. 
However, WithoutStrategies still can't work right now as a GraphSON serializer 
is missing for Type.




> Gremlin.Net: Generate completely type-safe methods
> --
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.5
>Reporter: Florian Hockmann
>Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params 
> object[] args}} as an argument which allows the user to provide an arbitrary 
> number of arguments with any type. While this makes the generation rather 
> simple, it doesn't tell the user which arguments are actually valid so users 
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users 
> something about what kind of values the methods expect. Consider for example 
> the following method signatures for the C# step {{AddE}} that are basically a 
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string 
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[] 
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve

[GitHub] tinkerpop pull request #712: TINKERPOP-1752: Gremlin.Net: Generate completel...

2017-09-12 Thread FlorianHockmann 
GitHub user FlorianHockmann opened a pull request:

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

TINKERPOP-1752: Gremlin.Net: Generate completely type-safe methods

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

All steps are now (basically) type-safe and the original argument names 
from Gremlin-Java are used. However, we currently don't support some Java types 
like `Comparator`. Those were simply replaced by `object` until we find a 
better solution. A problem with this workaround is that some overloads from 
Gremlin-Java are not supported in Gremlin.Net as they would result in the same 
method signature.

The implementation of `Bindings` is now basically the same as in 
Gremlin-Java. This change was necessary as `Bindings.Of()` can no longer return 
a `Binding` object

These changes also revealed a bug in the tests where the 
`WithoutStrategies` source step was called with objects of strategies instead 
of just with their types. However, `WithoutStrategies` still can't work right 
now as a GraphSON serializer is missing for `Type`.

The `Group` step for example looks now like this:
```cs
/// 
/// Adds the group step to this .
/// 
public GraphTraversal< S , IDictionary > Group ()
{
Bytecode.AddStep("group");
return Wrap< S , IDictionary >(this);
}

/// 
/// Adds the group step to this .
/// 
public GraphTraversal< S , E > Group (string sideEffectKey)
{
Bytecode.AddStep("group", sideEffectKey);
return Wrap< S , E >(this);
}
```
So this should also solve 
[TINKERPOP-1751](https://issues.apache.org/jira/browse/TINKERPOP-1751) that 
mentioned the missing overload for `Group` that returns `IDictionary`.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1752

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/712.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #712


commit 05851764f1e20abb1a82b7d662b4681d602a5774
Author: Florian Hockmann 
Date:   2017-08-17T20:57:07Z

Make Gremlin.Net graph traversal API type-safe

All steps are now type-safe and the original argument names from
Gremlin-Java are used. However, we currently don't support some Java
types like Comparator. Those were simply replaced by object until we
find a better solution. A problem of this workaround is that some
overloads from Gremlin-Java are not supported in Gremlin.Net as they
would result in the same method signature.
This required to change how Bindings work as Bindings.Of() can no longer
return a Binding object. The implementation for Bindings is now
basically the same as in Gremlin-Java.

This also revealed a bug in the tests that called the WithoutStrategies 
source step with objects of strategies instead of just with their types. 
However, WithoutStrategies still can't work right now as a GraphSON serializer 
is missing for Type.




---

[jira] [Closed] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.

2017-09-12 Thread Ted Wilmes (JIRA) 

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

Ted Wilmes closed TINKERPOP-1287.
-
Resolution: Not A Problem

Profiling did not show stream usage making a significant impact on performance 
in this case. The use of `intern` mentioned in the comments was taken care of 
by TINKERPOP-1680.

> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from 
> TinkerGraph made it much faster. It would be good if we did the same thing 
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.

2017-09-12 Thread Ted Wilmes (JIRA) 

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

Ted Wilmes commented on TINKERPOP-1287:
---

Not at this point [~spmallette], especially since the {{intern}} was taken care 
of. I'll go ahead and close it.

> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from 
> TinkerGraph made it much faster. It would be good if we did the same thing 
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TINKERPOP-1780) Add authentication tests for gremlin-python

2017-09-12 Thread stephen mallette (JIRA) 
stephen mallette created TINKERPOP-1780:
---

 Summary: Add authentication tests for gremlin-python
 Key: TINKERPOP-1780
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1780
 Project: TinkerPop
  Issue Type: Improvement
  Components: language-variant
Affects Versions: 3.2.6
Reporter: stephen mallette
Priority: Minor


Include integration tests for authentication in gremlin-python. There is a 
secure test server running with the tests on port 45941 so we should be all 
good to add a test or two to validate this operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1730) Gremlin .NET support for GraphSON 3.0

2017-09-12 Thread ASF GitHub Bot (JIRA) 

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

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

Github user FlorianHockmann commented on the issue:

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


> Gremlin .NET support for GraphSON 3.0
> -
>
> Key: TINKERPOP-1730
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1730
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Priority: Minor
>
> This may be a quite minor thing at this point as [~jorgebg] already had much 
> of this in place. GraphSON 3.0 should be the default for 3.3.0 - right now it 
> is set to 2.0 so all the tests pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #710: TINKERPOP-1730 Gremlin .NET: add support for GraphSON3

2017-09-12 Thread FlorianHockmann 
Github user FlorianHockmann commented on the issue:

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


---

[jira] [Commented] (TINKERPOP-1730) Gremlin .NET support for GraphSON 3.0

2017-09-12 Thread ASF GitHub Bot (JIRA) 

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

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

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

https://github.com/apache/tinkerpop/pull/710#discussion_r138366459
  
--- Diff: 
gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Process/Traversal/DriverRemoteConnection/GraphTraversalTests.cs
 ---
@@ -102,9 +102,9 @@ public void g_V_HasXname_markoX_ValueMap_Next()
 var connection = _connectionFactory.CreateRemoteConnection();
 var g = graph.Traversal().WithRemote(connection);
 
-var receivedValueMap = g.V().Has("name", 
"marko").ValueMap().Next();
+var receivedValueMap = g.V().Has("name", 
"marko").ValueMap().Next();
--- End diff --

Ah ok, I saw the thread on the mailing list, but somehow I didn't draw the 
connection to this change.


> Gremlin .NET support for GraphSON 3.0
> -
>
> Key: TINKERPOP-1730
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1730
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Priority: Minor
>
> This may be a quite minor thing at this point as [~jorgebg] already had much 
> of this in place. GraphSON 3.0 should be the default for 3.3.0 - right now it 
> is set to 2.0 so all the tests pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #710: TINKERPOP-1730 Gremlin .NET: add support for Gr...

2017-09-12 Thread FlorianHockmann 
Github user FlorianHockmann commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/710#discussion_r138366459
  
--- Diff: 
gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Process/Traversal/DriverRemoteConnection/GraphTraversalTests.cs
 ---
@@ -102,9 +102,9 @@ public void g_V_HasXname_markoX_ValueMap_Next()
 var connection = _connectionFactory.CreateRemoteConnection();
 var g = graph.Traversal().WithRemote(connection);
 
-var receivedValueMap = g.V().Has("name", 
"marko").ValueMap().Next();
+var receivedValueMap = g.V().Has("name", 
"marko").ValueMap().Next();
--- End diff --

Ah ok, I saw the thread on the mailing list, but somehow I didn't draw the 
connection to this change.


---

[jira] [Created] (TINKERPOP-1779) Bump to GMavenPlus 1.6

2017-09-12 Thread stephen mallette (JIRA) 
stephen mallette created TINKERPOP-1779:
---

 Summary: Bump to GMavenPlus 1.6
 Key: TINKERPOP-1779
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1779
 Project: TinkerPop
  Issue Type: Improvement
  Components: build-release
Affects Versions: 3.2.6
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor


The new version of GMavenPlus allows for a few new capabilities which we can 
make use of. Most useful is the ability to specify a groovy file for the 
{{execute}} goal. As we now make use of this goal in the GLVs pretty heavily we 
could greatly clean up the poms and make better re-use of code if that stuff 
could be pulled out into script files that could be referenced by any module 
that needs it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TINKERPOP-1778) Deprecate timedInterrupt option for Gremlin Server script processing

2017-09-12 Thread stephen mallette (JIRA) 
stephen mallette created TINKERPOP-1778:
---

 Summary: Deprecate timedInterrupt option for Gremlin Server script 
processing
 Key: TINKERPOP-1778
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1778
 Project: TinkerPop
  Issue Type: Improvement
  Components: server
Affects Versions: 3.2.6
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor


The {{timedInterrupt}} option is not terribly useful because it basically does 
what the combination of the regular {{scriptEvaluationTimeout}} with the 
{{enableThreadInterrupt}} does. In fact it sort of competes with it, which can 
lead to some different error paths which mean the same thing. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: GraphSON3 collections and subtypes

2017-09-12 Thread Jorge Bay Gondra 
Collections with unspecified child types are useful for mixed types, but we
are reusing those types of collections for all the cases.
This behaviour poses a problem for strict statically typed languages like
C#. Let's see if I can explain myself with an example:

valueMap() step yields a map representation. In GraphSON2, it was returned
as a js object (where keys are always strings), that were mapped to C#
Dictionary (equivalent of java's Map).
In GraphSON3, it's returned as a "g:Map", that is mapped to C#
Dictionary. As there is no type coercion (ie: type erasure
in java) for Dictionary to Dictionary, the
user is stuck with a unspecified map, which contains strings as keys.

This causes a problem in any statically typed languages (outside java
generics w/ type-erasure thingy).

There are workarounds (like exposing conversion methods or lazy
deserialization) but maybe we can tackle this at the source and try to
specify the child types on serialization when we have that information.

On Mon, Sep 11, 2017 at 6:04 PM, Stephen Mallette 
wrote:

> Mixed types would be the problem - that's why objects within the List/Map
> have types embedded within them.
>
> On Mon, Sep 11, 2017 at 12:01 PM, Robert Dale  wrote:
>
> > I'm not sure that's feasible since any list or map could contain mixed
> > types.  Maybe I don't understand the use case.
> >
> > Robert Dale
> >
> > On Mon, Sep 11, 2017 at 11:27 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > > wrote:
> >
> > > Hi,
> > > The new GraphSON3 g:List, g:Set and g:Map definitions are an
> improvement
> > > over js arrays and associative arrays, but they doesn't provide the
> child
> > > type information.
> > >
> > > We could add support for chid type info, something like
> > > "g:List" or "g:Map".
> > >
> > > For typed languages, it would allow compile time checks.
> > > For any technology, it would more user-friendly error messages
> ("Expected
> > > Vertex, obtained...").
> > >
> > > Jorge
> > >
> >
>

[GitHub] tinkerpop issue #710: TINKERPOP-1730 Gremlin .NET: add support for GraphSON3

2017-09-12 Thread jorgebay 
Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/710
  
Thanks @FlorianHockmann for the feedback.
I've addressed the issues you mentioned.

About `ValueMap()`, we can continue the discussion on the 
mailing list: 
https://lists.apache.org/thread.html/3918353aaa63aa07b69214da24fa7aa0760004227fc57fa2b3bcae86@%3Cdev.tinkerpop.apache.org%3E


---

[GitHub] tinkerpop pull request #710: TINKERPOP-1730 Gremlin .NET: add support for Gr...

2017-09-12 Thread jorgebay 
Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/710#discussion_r138317662
  
--- Diff: 
gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Process/Traversal/DriverRemoteConnection/GraphTraversalTests.cs
 ---
@@ -102,9 +102,9 @@ public void g_V_HasXname_markoX_ValueMap_Next()
 var connection = _connectionFactory.CreateRemoteConnection();
 var g = graph.Traversal().WithRemote(connection);
 
-var receivedValueMap = g.V().Has("name", 
"marko").ValueMap().Next();
+var receivedValueMap = g.V().Has("name", 
"marko").ValueMap().Next();
--- End diff --

The serialization format for maps changed (see JIRA tickets 1427 and 1658), 
the result from this traversal was originally a js object:

```js
{ "marko": { "@type": "g:Int32", "@value": 29 } }
```

And changed in GraphSON3 to a type "g:Map" for which we use 
`IDictionary`.

I've started a discussion on the mailing list regarding collections child 
types: 
https://lists.apache.org/thread.html/3918353aaa63aa07b69214da24fa7aa0760004227fc57fa2b3bcae86@%3Cdev.tinkerpop.apache.org%3E


---