[
https://issues.apache.org/jira/browse/TINKERPOP-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754149#comment-16754149
]
Ian Thomas commented on TINKERPOP-2145:
---------------------------------------
Thanks for the prompt responses!
I haven't had a chance to dig into the gremlin server/tinkergraph, but I will
do that if I can get to it soon or run out of ideas in the code itself. One
thing that seems to have revealed itself is that the format of the response
JSON coming back has changed. One of our main challenges using C# has been how
to cleanly deserialize the GraphSON format into reasonable C# POCOs.
We typically set JToken as our return type when executing queries
(client.SubmitAsync<JToken>), and it looks like changes in the format coming
back have changed the results of that deserialization when dealing with
collections of results. It seems the deserialization was hitting what it
thought was a stopping point and returning only partial data.
We think the difference came in with this code:
[https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Driver/SingleMessageResultReceiver.cs#L53]
We're still verifying, but believe we have fixed this by having the client
return `dynamic` (client.SubmitAsync<dynamic>) and turn it into a JToken
exclusively within our own code.
> Upgrading to 3.4.0 results in inconsistent query results
> --------------------------------------------------------
>
> Key: TINKERPOP-2145
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2145
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet
> Affects Versions: 3.4.0
> Environment: Azure CosmosDB, .NET Core 2.1
> Reporter: Ian Thomas
> Priority: Major
>
> I upgraded my application to use Gremlin.NET 3.4.0 in order to leverage the
> status attributes in the responses. In particular, I was looking for RU cost
> and throttled request retry time from Cosmos.
> In writing tests against this functionality to get into a throttled state, I
> started noticing that my queries were returning different results than
> expected.
> For example, the below queries differ only by the presence of the property on
> `valueMap`, but in testing, return different results. I haven't been able to
> determine any rule for how many results are missing, but the first query
> returns fewer results than the second. I imagine it is because there is less
> data coming across with the limited scope of properties, but I really don't
> have any idea.
> {code:java}
> g.V()
> .hasLabel('vertexlabel').not(has('Property', true)) .has('StartDate',
> lte(_EndDate)).valueMap(true)
> {code}
> {code:java}
> g.V()
> .hasLabel('vertexlabel').not(has('Property', true)) .has('StartDate',
> lte(_EndDate)).valueMap(true, 'StartDate')
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
