[
https://issues.apache.org/jira/browse/TINKERPOP-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754271#comment-16754271
]
Ian Thomas commented on TINKERPOP-2145:
---------------------------------------
I tested 3.3.5 this morning and didn't see any issues. I do definitely feel
like the issue occurs if the result is sent via multiple messages.
I tweaked my data locally and I got exactly the same results when there were 5
instances of the object, but the results got inconsistent as I scaled the
number of instances up within my unit test. When I wrote 18 instances, one
query returned all 18 and the other returned exactly 13 every single time. So
as I scaled up, the results started getting inconsistent. In addition, if I
added a projection to the query, it returned 7 instead of the full 18.
So, it was 18 -> 13 -> 7 results returned as query complexity grew, but small
datasets didn't drop results.
Basically, it seems like a sliding scale that dropped results as the query
result grew, which makes sense that it would be because of multiple messages.
> 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)
