[
https://issues.apache.org/jira/browse/TINKERPOP-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752692#comment-16752692
]
stephen mallette commented on TINKERPOP-2145:
---------------------------------------------
curious issue. i can't think of anything that would have changed between 3.3.x
and 3.4.0 that I would attribute to this problem from the TinkerPop
perspective.
note that 3.4.0 is mostly compatible with 3.3.x. I say it is "mostly
compatible" because there are Gremlin language changes in 3.4.0 that just won't
be available in earlier versions and if they are used will cause failures.
{{valueMap()}} did see some changes for 3.4.0:
http://tinkerpop.apache.org/docs/3.4.0/upgrade/#_modulation_of_valuemap
but I don't think that they would affect anything you are doing. In fact, we
mention in those upgrade docs that there is a breaking API change for it, but
that seems relevant to Java and not to .NET so even that shouldn't be an issue.
Further note that CosmosDB, to my knowledge, has not yet acknowledge support
for 3.4.0 on the server side so you sorta need to be careful about the features
of 3.4.0 that you are using on the client.
all that said, this kind of issue is notoriously hard to sort out because if it
only has reproduction steps on CosmosDB then it's obviously not something we
here at TinkerPop can easily test. I'd suggest two things as next steps from
your end:
1. i know it won't have the feature you want but do you mind trying 3.3.5 to
see if it works on that version (at least in that way it could be isolated as a
problem with 3.4.0).
2. If isolated to 3.4.0 try to recreate the issue with Gremlin Server and
TinkerGraph and see if you have any success there.
Depending on your findings from those two things, we can determine what to do
next. Thanks.
> 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)
