[
https://issues.apache.org/jira/browse/TINKERPOP-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754045#comment-16754045
]
Florian Hockmann commented on TINKERPOP-2145:
---------------------------------------------
Since you're using CosmosDB, you're sending these traversals as Gremlin-Groovy
strings to the server and not by using the Traversal API in C#, right?
> 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)
