[jira] [Commented] (TINKERPOP-1914) Support construct a GremlinServer instance from gremlin executor service
[ https://issues.apache.org/jira/browse/TINKERPOP-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16407371#comment-16407371 ] ASF GitHub Bot commented on TINKERPOP-1914: --- Github user javeme closed the pull request at: https://github.com/apache/tinkerpop/pull/813 > Support construct a GremlinServer instance from gremlin executor service > > > Key: TINKERPOP-1914 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1914 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Jermy Li >Assignee: stephen mallette >Priority: Major > Fix For: 3.3.2 > > > This constructor is useful when Gremlin Server is being used in an embedded > style and there is a need to share thread pools with the hosting application. > A constructor that can do this has been removed since: > [https://github.com/apache/tinkerpop/commit/67cd592742cc84cefdb1368a374119e7d4290e1e#diff-38a2e38559996e996423c0ca2ff597fbL128], > which results in incompatible with the existing code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop pull request #813: TINKERPOP-1914 Support construct a GremlinServe...
Github user javeme closed the pull request at: https://github.com/apache/tinkerpop/pull/813 ---
[jira] [Commented] (TINKERPOP-1758) RemoteStrategy should be before all other DecorationStrategies.
[
https://issues.apache.org/jira/browse/TINKERPOP-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406862#comment-16406862
]
ASF GitHub Bot commented on TINKERPOP-1758:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/811
fair enough - i kinda wanted to just fix this problem since it was out
there for so long. i'm hesitant to just hardcode the `RemoteStrategy` as
"first" - something feels off about doing that. perhaps we wait until this
approach presents as an issue before building lots of new infrastructure to
support something more flexible.
> RemoteStrategy should be before all other DecorationStrategies.
> ---
>
> Key: TINKERPOP-1758
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1758
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>
> {code}
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
> gremlin> g.V().out().out().values('name').explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> RemoteStrategy [D]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> MatchPredicateStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> FilterRankingStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> InlineFilterStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> IncidentToAdjacentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> AdjacentToIncidentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> RepeatUnrollStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> CountStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> PathRetractionStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> LazyBarrierStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphCountStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphStepStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> ProfileStrategy [F]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> StandardVerificationStrategy [V]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> Final Traversal
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #811: TINKERPOP-1758 Apply RemoteStrategy before all Decorat...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/811 fair enough - i kinda wanted to just fix this problem since it was out there for so long. i'm hesitant to just hardcode the `RemoteStrategy` as "first" - something feels off about doing that. perhaps we wait until this approach presents as an issue before building lots of new infrastructure to support something more flexible. ---
[GitHub] tinkerpop issue #811: TINKERPOP-1758 Apply RemoteStrategy before all Decorat...
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/811 I don't know. Just asking for the record. VOTE +1 ---
[jira] [Commented] (TINKERPOP-1758) RemoteStrategy should be before all other DecorationStrategies.
[
https://issues.apache.org/jira/browse/TINKERPOP-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406858#comment-16406858
]
ASF GitHub Bot commented on TINKERPOP-1758:
---
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/811
I don't know. Just asking for the record.
VOTE +1
> RemoteStrategy should be before all other DecorationStrategies.
> ---
>
> Key: TINKERPOP-1758
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1758
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>
> {code}
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
> gremlin> g.V().out().out().values('name').explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> RemoteStrategy [D]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> MatchPredicateStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> FilterRankingStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> InlineFilterStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> IncidentToAdjacentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> AdjacentToIncidentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> RepeatUnrollStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> CountStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> PathRetractionStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> LazyBarrierStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphCountStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphStepStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> ProfileStrategy [F]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> StandardVerificationStrategy [V]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> Final Traversal
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1758) RemoteStrategy should be before all other DecorationStrategies.
[
https://issues.apache.org/jira/browse/TINKERPOP-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406852#comment-16406852
]
ASF GitHub Bot commented on TINKERPOP-1758:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/811
no - this only works by convention @robertdale - i don't think there's a
way to do that short of scanning the classpath somehow for "decorations" and
ordering them properly. or perhaps something more drastic that mucked with
strategy ordering that always placed `RemoteStrategy` first, but i was hesitant
to mess with that too much. i dunno - am i not thinking of another way to
implement this?
> RemoteStrategy should be before all other DecorationStrategies.
> ---
>
> Key: TINKERPOP-1758
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1758
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>
> {code}
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
> gremlin> g.V().out().out().values('name').explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> RemoteStrategy [D]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> MatchPredicateStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> FilterRankingStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> InlineFilterStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> IncidentToAdjacentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> AdjacentToIncidentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> RepeatUnrollStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> CountStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> PathRetractionStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> LazyBarrierStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphCountStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphStepStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> ProfileStrategy [F]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> StandardVerificationStrategy [V]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> Final Traversal
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #811: TINKERPOP-1758 Apply RemoteStrategy before all Decorat...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/811 no - this only works by convention @robertdale - i don't think there's a way to do that short of scanning the classpath somehow for "decorations" and ordering them properly. or perhaps something more drastic that mucked with strategy ordering that always placed `RemoteStrategy` first, but i was hesitant to mess with that too much. i dunno - am i not thinking of another way to implement this? ---
[jira] [Commented] (TINKERPOP-1758) RemoteStrategy should be before all other DecorationStrategies.
[
https://issues.apache.org/jira/browse/TINKERPOP-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406844#comment-16406844
]
ASF GitHub Bot commented on TINKERPOP-1758:
---
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/811
Does this handle custom strategies?
> RemoteStrategy should be before all other DecorationStrategies.
> ---
>
> Key: TINKERPOP-1758
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1758
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.6
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
>
> {code}
> gremlin> g = graph.traversal().withRemote('conf/remote-graph.properties')
> ==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
> gremlin> g.V().out().out().values('name').explain()
> ==>Traversal Explanation
> ===
> Original Traversal [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> ConnectiveStrategy [D] [GraphStep(vertex,[]),
> VertexStep(OUT,vertex), VertexStep(OUT,vertex), PropertiesStep([name],value)]
> RemoteStrategy [D]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> MatchPredicateStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> FilterRankingStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> InlineFilterStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> IncidentToAdjacentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> AdjacentToIncidentStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> RepeatUnrollStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> CountStrategy[O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> PathRetractionStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> LazyBarrierStrategy [O]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphCountStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> TinkerGraphStepStrategy [P]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> ProfileStrategy [F]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> StandardVerificationStrategy [V]
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> Final Traversal
> [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]
> gremlin>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #811: TINKERPOP-1758 Apply RemoteStrategy before all Decorat...
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/811 Does this handle custom strategies? ---
[jira] [Commented] (TINKERPOP-1914) Support construct a GremlinServer instance from gremlin executor service
[ https://issues.apache.org/jira/browse/TINKERPOP-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406562#comment-16406562 ] ASF GitHub Bot commented on TINKERPOP-1914: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/821 > Support construct a GremlinServer instance from gremlin executor service > > > Key: TINKERPOP-1914 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1914 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Jermy Li >Assignee: stephen mallette >Priority: Major > Fix For: 3.3.2 > > > This constructor is useful when Gremlin Server is being used in an embedded > style and there is a need to share thread pools with the hosting application. > A constructor that can do this has been removed since: > [https://github.com/apache/tinkerpop/commit/67cd592742cc84cefdb1368a374119e7d4290e1e#diff-38a2e38559996e996423c0ca2ff597fbL128], > which results in incompatible with the existing code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop pull request #821: TINKERPOP-1914 Support construct a GremlinServe...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/821 ---
[jira] [Closed] (TINKERPOP-1914) Support construct a GremlinServer instance from gremlin executor service
[ https://issues.apache.org/jira/browse/TINKERPOP-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1914. --- Resolution: Done Assignee: stephen mallette Fix Version/s: 3.3.2 > Support construct a GremlinServer instance from gremlin executor service > > > Key: TINKERPOP-1914 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1914 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Jermy Li >Assignee: stephen mallette >Priority: Major > Fix For: 3.3.2 > > > This constructor is useful when Gremlin Server is being used in an embedded > style and there is a need to share thread pools with the hosting application. > A constructor that can do this has been removed since: > [https://github.com/apache/tinkerpop/commit/67cd592742cc84cefdb1368a374119e7d4290e1e#diff-38a2e38559996e996423c0ca2ff597fbL128], > which results in incompatible with the existing code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1914) Support construct a GremlinServer instance from gremlin executor service
[ https://issues.apache.org/jira/browse/TINKERPOP-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406481#comment-16406481 ] ASF GitHub Bot commented on TINKERPOP-1914: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/813 ok - thanks. would you mind closing this PR please? i will merge forward the other one to master. > Support construct a GremlinServer instance from gremlin executor service > > > Key: TINKERPOP-1914 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1914 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Jermy Li >Priority: Major > > This constructor is useful when Gremlin Server is being used in an embedded > style and there is a need to share thread pools with the hosting application. > A constructor that can do this has been removed since: > [https://github.com/apache/tinkerpop/commit/67cd592742cc84cefdb1368a374119e7d4290e1e#diff-38a2e38559996e996423c0ca2ff597fbL128], > which results in incompatible with the existing code. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #813: TINKERPOP-1914 Support construct a GremlinServer insta...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/813 ok - thanks. would you mind closing this PR please? i will merge forward the other one to master. ---
[jira] [Commented] (TINKERPOP-1865) Run Gremlin .NET GLV tests with GraphSON 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406313#comment-16406313 ] ASF GitHub Bot commented on TINKERPOP-1865: --- Github user FlorianHockmann commented on the issue: https://github.com/apache/tinkerpop/pull/820 Ok, I created [TINKERPOP-1927](https://issues.apache.org/jira/browse/TINKERPOP-1927) to fix the scenarios. VOTE +1 > Run Gremlin .NET GLV tests with GraphSON 3.0 > > > Key: TINKERPOP-1865 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1865 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.1 >Reporter: stephen mallette >Assignee: Jorge Bay >Priority: Major > Fix For: 3.3.2 > > > GLV tests currently run for GraphSON 2.0 with .NET - they should be running > for 3.0 especially on the 3.3.x line of code. Ideally we should probably run > tests for both versions, but perhaps that is a separate issue at this point > as it is for Python on TINKERPOP-1864 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #820: TINKERPOP-1865 Run Gremlin.Net tests with GraphSON 3.0
Github user FlorianHockmann commented on the issue: https://github.com/apache/tinkerpop/pull/820 Ok, I created [TINKERPOP-1927](https://issues.apache.org/jira/browse/TINKERPOP-1927) to fix the scenarios. VOTE +1 ---
[jira] [Updated] (TINKERPOP-1927) Gherkin scenario expects list with duplicates, but receives g:Set
[
https://issues.apache.org/jira/browse/TINKERPOP-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann updated TINKERPOP-1927:
Description:
The scenario
{{g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX}}
expects
{code:java}
| result |
| d[1].l |
| d[1].l |
| d[0].l |
| d[0].l |
| d[0].l |
| d[2].l |
| d[1.0].d |
| d[1.0].d |
{code}
but we receive this from the server:
{code:java}
{
"@type": "g:Set",
"@value": [
{
"@type": "g:Int64",
"@value": 1
},
{
"@type": "g:Int64",
"@value": 1
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 2
},
{
"@type": "g:Double",
"@value": 1
},
{
"@type": "g:Double",
"@value": 1
}
]
}
{code}
The set returned by the server contains 4 duplicates that shouldn't be part of
the expected result in the scenario.
Unfortunately, while working on TINKERPOP-1865 we noticed that gremlin-python
and gremlin-javascript fail when the scenario is fixed like that. So those two
GLVs probably need to be fixed to handle {{g:Set}} correctly.
After fixing the scenario, it can be removed from the list of ignored scenarios
in Gremlin.Net.
was:
The scenario
{{g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX}}
expects
{code:java}
| result |
| d[1].l |
| d[1].l |
| d[0].l |
| d[0].l |
| d[0].l |
| d[2].l |
| d[1.0].d |
| d[1.0].d |
{code}
but we receive this from the server:
{code:java}
{
"@type": "g:Set",
"@value": [
{
"@type": "g:Int64",
"@value": 1
},
{
"@type": "g:Int64",
"@value": 1
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 2
},
{
"@type": "g:Double",
"@value": 1
},
{
"@type": "g:Double",
"@value": 1
}
]
}
{code}
The set returned by the server contains 4 duplicates that shouldn't be part of
the expected result in the scenario.
Unfortunately, while working on TINKERPOP-1865 we noticed that gremlin-python
and gremlin-javascript fail when the scenario is fixed like that. So those two
GLVs probably need to be fixed to handle {{g:Set}} correctly.
> Gherkin scenario expects list with duplicates, but receives g:Set
> -
>
> Key: TINKERPOP-1927
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1927
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet, javascript, python, test-suite
>Affects Versions: 3.3.1
>Reporter: Florian Hockmann
>Priority: Major
>
> The scenario
> {{g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX}}
> expects
> {code:java}
> | result |
> | d[1].l |
> | d[1].l |
> | d[0].l |
> | d[0].l |
> | d[0].l |
> | d[2].l |
> | d[1.0].d |
> | d[1.0].d |
> {code}
> but we receive this from the server:
> {code:java}
> {
> "@type": "g:Set",
> "@value": [
> {
> "@type": "g:Int64",
> "@value": 1
> },
> {
> "@type": "g:Int64",
> "@value": 1
> },
> {
> "@type": "g:Int64",
> "@value": 0
> },
> {
> "@type": "g:Int64",
> "@value": 0
> },
> {
> "@type": "g:Int64",
> "@value": 0
> },
> {
> "@type": "g:Int64",
> "@value": 2
> },
> {
> "@type": "g:Double",
> "@value": 1
> },
> {
> "@type": "g:Double",
> "@value": 1
> }
> ]
> }
> {code}
> The set returned by the server contains 4 duplicates that shouldn't be part
> of the expected result in the scenario.
> Unfortunately, while working on TINKERPOP-1865 we noticed that gremlin-python
> and gremlin-javascript fail when the scenario is fixed like that. So those
> two GLVs probably need to be fixed to handle {{g:Set}} correctly.
> After fixing the scenario, it can be removed from the list of ignored
> scenarios in Gremlin.Net.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-1927) Gherkin scenario expects list with duplicates, but receives g:Set
Florian Hockmann created TINKERPOP-1927:
---
Summary: Gherkin scenario expects list with duplicates, but
receives g:Set
Key: TINKERPOP-1927
URL: https://issues.apache.org/jira/browse/TINKERPOP-1927
Project: TinkerPop
Issue Type: Bug
Components: dotnet, javascript, python, test-suite
Affects Versions: 3.3.1
Reporter: Florian Hockmann
The scenario
{{g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX}}
expects
{code:java}
| result |
| d[1].l |
| d[1].l |
| d[0].l |
| d[0].l |
| d[0].l |
| d[2].l |
| d[1.0].d |
| d[1.0].d |
{code}
but we receive this from the server:
{code:java}
{
"@type": "g:Set",
"@value": [
{
"@type": "g:Int64",
"@value": 1
},
{
"@type": "g:Int64",
"@value": 1
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 0
},
{
"@type": "g:Int64",
"@value": 2
},
{
"@type": "g:Double",
"@value": 1
},
{
"@type": "g:Double",
"@value": 1
}
]
}
{code}
The set returned by the server contains 4 duplicates that shouldn't be part of
the expected result in the scenario.
Unfortunately, while working on TINKERPOP-1865 we noticed that gremlin-python
and gremlin-javascript fail when the scenario is fixed like that. So those two
GLVs probably need to be fixed to handle {{g:Set}} correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1865) Run Gremlin .NET GLV tests with GraphSON 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406297#comment-16406297 ] ASF GitHub Bot commented on TINKERPOP-1865: --- Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/820 I agree, we should fix `g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX` outside of this pr. Having the gherkin based tests running on GraphSON3 for Gremlin.NET is a huge improvement, VOTE +1 > Run Gremlin .NET GLV tests with GraphSON 3.0 > > > Key: TINKERPOP-1865 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1865 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.1 >Reporter: stephen mallette >Assignee: Jorge Bay >Priority: Major > Fix For: 3.3.2 > > > GLV tests currently run for GraphSON 2.0 with .NET - they should be running > for 3.0 especially on the 3.3.x line of code. Ideally we should probably run > tests for both versions, but perhaps that is a separate issue at this point > as it is for Python on TINKERPOP-1864 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #820: TINKERPOP-1865 Run Gremlin.Net tests with GraphSON 3.0
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/820 I agree, we should fix `g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX` outside of this pr. Having the gherkin based tests running on GraphSON3 for Gremlin.NET is a huge improvement, VOTE +1 ---
Re: [DISCUSS] Use error-prone java compiler
In general, I am +1 on adding a static analysis tool to our tool chain. I just wonder whether a Java compiler is the best choice for us right now or whether other static analysis tools would find most of the problems that such a compiler can find and also work with other languages than Java. SonarQube[1] for example looks pretty nice. It also supports Python, C#, and JavaScript and we can probably just integrate it via GitHub to generate reports for the release branches and all PRs where it would then add issues in the form of inline comments. [1] https://www.sonarqube.org/ Am 20.03.2018 um 03:42 schrieb Robert Dale: > Some changes look good others look wrong evident by the failed builds. I > think any proposed changes would be separate PRs and reviewed on a > case-by-case basis. As for making it the default compiler, I think this > would be a profile, disabled by default, at best at least until a time it > can be massaged to where it works for this project. > > On Mon, Mar 19, 2018 at 14:59 Roman Leventov wrote: > >> See https://github.com/apache/tinkerpop/pull/819. >> >> 1) Are there any objections to using error-prone compiler instead of >> OpenJDK's javac compiler? >> 2) Stephen raised the question, that Tinkerpop project may better use >> another static analysis tool instead of error-prone. I have to answer that >> no static analysis tool covers 100% of the errors found by any other tool, >> so running more tools is always better. >> 3) Stephen raised the question, what checks should be enabled. I believe >> this is out of scope of the PR ( >> https://github.com/apache/tinkerpop/pull/819), >> because it doesn't (and doesn't intent to) enable any more checks beyond >> the default (= minimal) set of error patterns. More checks may or may not >> be enabled in later PRs and that could be discussed separately. >>
[jira] [Commented] (TINKERPOP-1865) Run Gremlin .NET GLV tests with GraphSON 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406231#comment-16406231 ] ASF GitHub Bot commented on TINKERPOP-1865: --- Github user FlorianHockmann commented on the issue: https://github.com/apache/tinkerpop/pull/820 > Also, I've switched to use a lambda (now that we support it :) ) to obtain all the edges for the scenario data, That lambda really makes the traversal much easier to read and understand :) For `g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX`, I'd say that we should change the scenario to only expect the 4 unique values and then fix gremlin-python and gremlin-javascript as they seem to deserialize sets incorrectly at the moment. (Otherwise they had to fail for this test at the moment.) But I'm not sure if we want to do all that in this PR. > @FlorianHockmann I hope you don't mind that I've directly pushed to the dev branch, feel free to revert the commits if needed. Certainly not, thanks for helping me with this PR! > Run Gremlin .NET GLV tests with GraphSON 3.0 > > > Key: TINKERPOP-1865 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1865 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.1 >Reporter: stephen mallette >Assignee: Jorge Bay >Priority: Major > Fix For: 3.3.2 > > > GLV tests currently run for GraphSON 2.0 with .NET - they should be running > for 3.0 especially on the 3.3.x line of code. Ideally we should probably run > tests for both versions, but perhaps that is a separate issue at this point > as it is for Python on TINKERPOP-1864 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #820: TINKERPOP-1865 Run Gremlin.Net tests with GraphSON 3.0
Github user FlorianHockmann commented on the issue: https://github.com/apache/tinkerpop/pull/820 > Also, I've switched to use a lambda (now that we support it :) ) to obtain all the edges for the scenario data, That lambda really makes the traversal much easier to read and understand :) For `g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX`, I'd say that we should change the scenario to only expect the 4 unique values and then fix gremlin-python and gremlin-javascript as they seem to deserialize sets incorrectly at the moment. (Otherwise they had to fail for this test at the moment.) But I'm not sure if we want to do all that in this PR. > @FlorianHockmann I hope you don't mind that I've directly pushed to the dev branch, feel free to revert the commits if needed. Certainly not, thanks for helping me with this PR! ---
[jira] [Commented] (TINKERPOP-1865) Run Gremlin .NET GLV tests with GraphSON 3.0
[
https://issues.apache.org/jira/browse/TINKERPOP-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406011#comment-16406011
]
ASF GitHub Bot commented on TINKERPOP-1865:
---
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/820
I've rebased this branch to get the fixes for `P.within()` from #817.
Also, I've switched to use a lambda (now that we support it :) ) to obtain
all the edges for the scenario data, that way we use the same traversal as
Python. It would be nice to backport the same traversal for `tp32` but it's not
necessary for now.
About
`g_VX1X_hasXlabel_personX_mapXmapXint_ageXX_orderXlocalX_byXvalues_decrX_byXkeys_incrX`,
I've changed the lambda to return a `Map`.
Regarding
`g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX`,
its still ignored as the returned data doesn't match, it returns:
```javascript
{ '@type': 'g:Set',
'@value':
[ { '@type': 'g:Int64', '@value': 1 },
{ '@type': 'g:Int64', '@value': 1 },
{ '@type': 'g:Int64', '@value': 0 },
{ '@type': 'g:Int64', '@value': 0 },
{ '@type': 'g:Int64', '@value': 0 },
{ '@type': 'g:Int64', '@value': 2 },
{ '@type': 'g:Double', '@value': 1 },
{ '@type': 'g:Double', '@value': 1 }
```
Which is deserialized into a `Set` containing only the different
values (4 values in total), so it's a scenario design issue (not related to
Gremlin.NET).
@FlorianHockmann I hope you don't mind that I've directly pushed to the dev
branch, feel free to revert the commits if needed.
> Run Gremlin .NET GLV tests with GraphSON 3.0
>
>
> Key: TINKERPOP-1865
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1865
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.1
>Reporter: stephen mallette
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.3.2
>
>
> GLV tests currently run for GraphSON 2.0 with .NET - they should be running
> for 3.0 especially on the 3.3.x line of code. Ideally we should probably run
> tests for both versions, but perhaps that is a separate issue at this point
> as it is for Python on TINKERPOP-1864
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #820: TINKERPOP-1865 Run Gremlin.Net tests with GraphSON 3.0
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/820
I've rebased this branch to get the fixes for `P.within()` from #817.
Also, I've switched to use a lambda (now that we support it :) ) to obtain
all the edges for the scenario data, that way we use the same traversal as
Python. It would be nice to backport the same traversal for `tp32` but it's not
necessary for now.
About
`g_VX1X_hasXlabel_personX_mapXmapXint_ageXX_orderXlocalX_byXvalues_decrX_byXkeys_incrX`,
I've changed the lambda to return a `Map`.
Regarding
`g_V_storeXaX_byXoutEXcreatedX_countX_out_out_storeXaX_byXinEXcreatedX_weight_sumX`,
its still ignored as the returned data doesn't match, it returns:
```javascript
{ '@type': 'g:Set',
'@value':
[ { '@type': 'g:Int64', '@value': 1 },
{ '@type': 'g:Int64', '@value': 1 },
{ '@type': 'g:Int64', '@value': 0 },
{ '@type': 'g:Int64', '@value': 0 },
{ '@type': 'g:Int64', '@value': 0 },
{ '@type': 'g:Int64', '@value': 2 },
{ '@type': 'g:Double', '@value': 1 },
{ '@type': 'g:Double', '@value': 1 }
```
Which is deserialized into a `Set` containing only the different
values (4 values in total), so it's a scenario design issue (not related to
Gremlin.NET).
@FlorianHockmann I hope you don't mind that I've directly pushed to the dev
branch, feel free to revert the commits if needed.
---
