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

Reply via email to