[
https://issues.apache.org/jira/browse/TINKERPOP-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752704#comment-16752704
]
Ian Thomas commented on TINKERPOP-2145:
---------------------------------------
Thanks for the information! I'm testing out different versions of gremlin.net
currently, between 3.3.3 and 3.4.0 and see if I can isolate where the results
started changing. I'll also tweak my queries that use `valueMap(true)` based
on those docs you shared.
It is also worth noting that we have a thin wrapper around gremlin.net to
insulate against https://issues.apache.org/jira/browse/TINKERPOP-2090 and
similar issues. It also has a little bit of deserialization code that we're
currently testing to rule that out as a cause.
Really my only need for 3.4.0 was that it was suppose to be the version where
we can get the metadata about the request back from Cosmos. We currently have
no insight into how much our requests are costing (Cosmos RUs), and we are at
the point where we need to optimize them based on what Cosmos is telling us.
We also need that metadata in the request exception to tell us how long to wait
before retrying.
I'll report back with any conclusions I reach.
> 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)
