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

Florian Hockmann commented on TINKERPOP-2145:
---------------------------------------------

That's strange. Gremlin.Net [has a 
test|https://github.com/apache/tinkerpop/blob/ab753950958a505c215b338e1424a8c8140871c5/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Driver/GremlinClientTests.cs#L138]
 to ensure that the aggregation of results across multiple received messages.

Now it would be really helpful if you could try to reproduce the problem with 
just Gremlin Server and TinkerGraph. You can also use [the Docker 
image|https://hub.docker.com/r/tinkerpop/gremlin-server/] for that.

> 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)

Reply via email to