[
https://issues.apache.org/jira/browse/TINKERPOP-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754232#comment-16754232
]
Florian Hockmann commented on TINKERPOP-2145:
---------------------------------------------
{quote}We typically set JToken as our return type when executing queries
(client.SubmitAsync<JToken>)
{quote}
That's good to know as it makes the changes introduced by TINKERPOP-2067 a
likely candidate for the changed behaviour you're observing. The idea in that
ticket was basically that the deserialization of results can be skipped if
{{JToken}} is specified as the return type so that users can perform the
deserialization themselves. You can confirm that this actually introduced the
problem if you compare versions 3.3.4 and 3.3.5 as the change also landed in
3.3.5 and there weren't any other changes in the Gremlin.Net driver between
those two versions ([version
diff|https://github.com/apache/tinkerpop/compare/3.3.4..3.3.5]).
How many results do you expect with that query and your graph? I wonder whether
the problem only occurs if the result is sent via multiple messages instead of
just one. The database could use more messages in your first query as that
returns all properties whereas the second traversal only returns one property
(+ label and vertex id for both traversals).
> 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)
