[jira] [Closed] (TINKERPOP-2145) Upgrading to 3.4.0 results in inconsistent query results

["stephen mallette (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stephen mallette closed TINKERPOP-2145.
---------------------------------------
    Resolution: Incomplete

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