[DISCUSS] Gorilla Web Toolkit archived - Potentially impacting Gremlin Go GLV
Hi All, I just want to raise this particular fact to attention, the Gorilla Web Toolkit just became a public archive on Dec 9 (more information https://github.com/gorilla#gorilla-toolkit). As Gorilla WebSocket is the most widely used websocket library, we are using it in the Gremlin Go GLV. There should not be any immediate impact on Gremlin Go, as this library has been stable and used in production for the past decade, however there could be potential issues down the road. Unfortunately, despite its wide usage (Docker for example), there has not been much discussion around alternatives, and a lot of current consensus is to continue using the library. A repository has been created recently in an effort to revive the project, https://github.com/GorillaIncubator, but I think many people are still on the outlook. I believe for now it is sufficient to keep using the Gorilla WebSocket library and monitor the community for updates. We could potentially swap out the Gorilla WebSocket for alternative ones, for example, https://godoc.org/nhooyr.io/websocket, but some effort will be needed to investigate and find a suitable, actively maintained alternative. It would be great if anyone familiar with the issue has suggestions. Cheers, Yang *--* *Yang Xia* Software Engineer Improving Vancouver yang@improving.com This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank you.
[jira] [Updated] (TINKERPOP-2836) Github actions do not run java driver integration tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cole Greer updated TINKERPOP-2836: -- Summary: Github actions do not run java driver integration tests (was: Github actions do not run java driver integration tests/) > Github actions do not run java driver integration tests > --- > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2836) Github actions do not run java driver integration tests/
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia resolved TINKERPOP-2836. - Resolution: Fixed > Github actions do not run java driver integration tests/ > > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2836) Github actions do not run java driver integration tests/
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646882#comment-17646882 ] ASF GitHub Bot commented on TINKERPOP-2836: --- xiazcy merged PR #1903: URL: https://github.com/apache/tinkerpop/pull/1903 > Github actions do not run java driver integration tests/ > > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2836) Github actions do not run java driver integration tests/
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646881#comment-17646881 ] ASF GitHub Bot commented on TINKERPOP-2836: --- xiazcy commented on PR #1903: URL: https://github.com/apache/tinkerpop/pull/1903#issuecomment-1350155598 Merging this as it's part of #1891 > Github actions do not run java driver integration tests/ > > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2836) Github actions do not run java driver integration tests/
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646879#comment-17646879 ] ASF GitHub Bot commented on TINKERPOP-2836: --- xiazcy commented on PR #1891: URL: https://github.com/apache/tinkerpop/pull/1891#issuecomment-1350148886 VOTE +1, merging since this has past 7 days and is just impacting testing environment. > Github actions do not run java driver integration tests/ > > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2836) Github actions do not run java driver integration tests/
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646880#comment-17646880 ] ASF GitHub Bot commented on TINKERPOP-2836: --- xiazcy merged PR #1891: URL: https://github.com/apache/tinkerpop/pull/1891 > Github actions do not run java driver integration tests/ > > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2819) Refactor SimpleSocketServer to be accessible to all GLV's
[ https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646877#comment-17646877 ] Yang Xia commented on TINKERPOP-2819: - Currently pending integration tests from GLVs, will close this after those are done. > Refactor SimpleSocketServer to be accessible to all GLV's > - > > Key: TINKERPOP-2819 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2819 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Cole Greer >Priority: Major > > Currently there is a large gap in the testing capabilities of the java driver > compared to the other GLV's. Part of this gap is the java driver has > SimpleSocketServer which provides a useful platform to write tests which > require specific response behaviour from the server. Having such a tool for > all of the GLV's would allow for testing of many more potential failure cases > as well as taking a step towards standardizing the testing approach for all > GLV's. > This work can be divided into 2 main parts. > Part One: Decoupling SimpleSocketServer from the java driver. This is the > most disruptive part of the proposed changes. This has already been discussed > [here|https://lists.apache.org/thread/vd7w43xjzvc5rr0135gql9mxhdlcltr9] on > the dev list but I will summarize. To avoid having all the GLV's depending on > the java driver, SimpleSocketServer and it's related classes should be > extracted to a new module gremlin-tools/gremlin-socket-server. Unfortunately > the socket server still relies on the following classes in gremlin driver: > tinkerpop.gremlin.driver.message.* > tinkerpop.gremlin.driver.ser.* > tinkerpop.gremlin.driver.MessageSerializer > tinkerpop.gremlin.driver.Tokens > To avoid a cyclic dependency between gremlin-driver and > gremlin-socket-server. these classes should be moved to another new module > gremlin-util which will house any classes which are to be shared between the > driver and server. Moving these classes to a new module and package will > break import lines and will need to be left until 3.7. > The full list of classes moved into gremlin-util is as follows: > > ||Old Name/Location||New Name/Location|| > |org.apache.tinkerpop.gremlin.driver.MessageSerializer|org.apache.tinkerpop.gremlin.util.MessageSerializer| > |org.apache.tinkerpop.gremlin.driver.Tokens|org.apache.tinkerpop.gremlin.util.Tokens| > |org.apache.tinkerpop.gremlin.driver.message.RequestMessage|org.apache.tinkerpop.gremlin.util.message.RequestMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseMessage|org.apache.tinkerpop.gremlin.util.message.ResponseMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseResult|org.apache.tinkerpop.gremlin.util.message.ResponseResult| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatus|org.apache.tinkerpop.gremlin.util.message.ResponseStatus| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatusCode|org.apache.tinkerpop.gremlin.util.message.ResponseStatusCode| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractMessageSerializer|org.apache.tinkerpop.gremlin.util.ser.AbstractMessageSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1|org.apache.tinkerpop.gremlin.util.ser.GraphBinaryMessageSerializerV1| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV3d0| > |org.apache.tinkerpop.gremlin.driver.ser.MessageTextSerializer|org.apache.tinkerpop.gremlin.util.ser.MessageTextSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBuffer|org.apache.tinkerpop.gremlin.util.ser.NettyBuffer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBufferFactory|org.apache.tinkerpop.gremlin.util.ser.NettyBufferFactory| >
[jira] [Commented] (TINKERPOP-2819) Refactor SimpleSocketServer to be accessible to all GLV's
[ https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646875#comment-17646875 ] ASF GitHub Bot commented on TINKERPOP-2819: --- xiazcy merged PR #1897: URL: https://github.com/apache/tinkerpop/pull/1897 > Refactor SimpleSocketServer to be accessible to all GLV's > - > > Key: TINKERPOP-2819 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2819 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Cole Greer >Priority: Major > > Currently there is a large gap in the testing capabilities of the java driver > compared to the other GLV's. Part of this gap is the java driver has > SimpleSocketServer which provides a useful platform to write tests which > require specific response behaviour from the server. Having such a tool for > all of the GLV's would allow for testing of many more potential failure cases > as well as taking a step towards standardizing the testing approach for all > GLV's. > This work can be divided into 2 main parts. > Part One: Decoupling SimpleSocketServer from the java driver. This is the > most disruptive part of the proposed changes. This has already been discussed > [here|https://lists.apache.org/thread/vd7w43xjzvc5rr0135gql9mxhdlcltr9] on > the dev list but I will summarize. To avoid having all the GLV's depending on > the java driver, SimpleSocketServer and it's related classes should be > extracted to a new module gremlin-tools/gremlin-socket-server. Unfortunately > the socket server still relies on the following classes in gremlin driver: > tinkerpop.gremlin.driver.message.* > tinkerpop.gremlin.driver.ser.* > tinkerpop.gremlin.driver.MessageSerializer > tinkerpop.gremlin.driver.Tokens > To avoid a cyclic dependency between gremlin-driver and > gremlin-socket-server. these classes should be moved to another new module > gremlin-util which will house any classes which are to be shared between the > driver and server. Moving these classes to a new module and package will > break import lines and will need to be left until 3.7. > The full list of classes moved into gremlin-util is as follows: > > ||Old Name/Location||New Name/Location|| > |org.apache.tinkerpop.gremlin.driver.MessageSerializer|org.apache.tinkerpop.gremlin.util.MessageSerializer| > |org.apache.tinkerpop.gremlin.driver.Tokens|org.apache.tinkerpop.gremlin.util.Tokens| > |org.apache.tinkerpop.gremlin.driver.message.RequestMessage|org.apache.tinkerpop.gremlin.util.message.RequestMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseMessage|org.apache.tinkerpop.gremlin.util.message.ResponseMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseResult|org.apache.tinkerpop.gremlin.util.message.ResponseResult| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatus|org.apache.tinkerpop.gremlin.util.message.ResponseStatus| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatusCode|org.apache.tinkerpop.gremlin.util.message.ResponseStatusCode| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractMessageSerializer|org.apache.tinkerpop.gremlin.util.ser.AbstractMessageSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1|org.apache.tinkerpop.gremlin.util.ser.GraphBinaryMessageSerializerV1| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV3d0| > |org.apache.tinkerpop.gremlin.driver.ser.MessageTextSerializer|org.apache.tinkerpop.gremlin.util.ser.MessageTextSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBuffer|org.apache.tinkerpop.gremlin.util.ser.NettyBuffer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBufferFactory|org.apache.tinkerpop.gremlin.util.ser.NettyBufferFactory| >
[jira] [Updated] (TINKERPOP-2841) Test and Fix Per Request Settings in Go
[ https://issues.apache.org/jira/browse/TINKERPOP-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cole Greer updated TINKERPOP-2841: -- Issue Type: Improvement (was: Test) > Test and Fix Per Request Settings in Go > --- > > Key: TINKERPOP-2841 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2841 > Project: TinkerPop > Issue Type: Improvement > Components: go >Affects Versions: 3.7.0, 3.6.1, 3.5.4 >Reporter: Cole Greer >Priority: Major > > Gremlin go gives the option to override certain settings on a per request > basis (detailed > [here|https://tinkerpop.apache.org/docs/current/reference/#_per_request_settings_4]). > It's been observed that when overriding the requestId, gremlin go will still > make and use a new requestId instead > ([here|https://github.com/apache/tinkerpop/blob/master/gremlin-go/driver/request.go#L54]). > All documented per request settings need to be tested and fixed if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-2841) Test and Fix Per Request Settings in Go
Cole Greer created TINKERPOP-2841: - Summary: Test and Fix Per Request Settings in Go Key: TINKERPOP-2841 URL: https://issues.apache.org/jira/browse/TINKERPOP-2841 Project: TinkerPop Issue Type: Test Components: go Affects Versions: 3.5.4, 3.6.1, 3.7.0 Reporter: Cole Greer Gremlin go gives the option to override certain settings on a per request basis (detailed [here|https://tinkerpop.apache.org/docs/current/reference/#_per_request_settings_4]). It's been observed that when overriding the requestId, gremlin go will still make and use a new requestId instead ([here|https://github.com/apache/tinkerpop/blob/master/gremlin-go/driver/request.go#L54]). All documented per request settings need to be tested and fixed if needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646847#comment-17646847
]
ASF GitHub Bot commented on TINKERPOP-2816:
---
vkagamlyk merged PR #1892:
URL: https://github.com/apache/tinkerpop/pull/1892
> Gherkin test issues for implementers
>
>
> Key: TINKERPOP-2816
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2816
> Project: TinkerPop
> Issue Type: Bug
> Components: test-suite
>Affects Versions: 3.6.1
>Reporter: pieter martin
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
>
> Sqlg is encountering some issues when running the Gherkin feature tests.
> h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> {code:java}
> Scenario:
> g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> Given the modern graph
> And the traversal of
> """
>
> g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
> """
> When iterated next
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | ripple |
> {code}
> This test assumes an implicit order in the traversal. To fix the test we need
> to add in an {{order().by("name")}}
> {code:java}
> Scenario:
> g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> Given the modern graph
> And the traversal of
> """
> g.V().repeat(__.out().repeat(__.out().order().by("name",
> Order.desc)).times(1)).times(1).limit(1).path().by("name")
> """
> When iterated next
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | ripple |
> {code}
> h2. g_V_both_both_dedup_byXoutE_countX_name
> {code:java}
> Scenario: g_V_both_both_dedup_byXoutE_countX_name
> Given the modern graph
> And the traversal of
> """
> g.V().both().both().dedup().by(__.outE().count()).values("name")
> """
> When iterated to list
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | peter |
> | ripple |
> {code}
> This test assumes the order of {{{}V().both().both(){}}}.
> Unfortunately putting in an {{order().by("name")}} does not help. This is
> because of a second bug where {{TinkerPop}} is rewriting the steps
> incorrectly.
> {code:java}
> @Test
> public void testDedupSteps() {
> final TinkerGraph g = TinkerFactory.createModern();
> GraphTraversal traversal =
> g.traversal().V().both().both().order().by("name",
> Order.asc).dedup().by(__.outE().count()).values("name");
> traversal.hasNext();
> System.out.println(((DefaultGraphTraversal)traversal).getSteps());
> }
> {code}
> This produces,
> {code:java}
> [TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
> VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
> CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
> (null)])]), asc]]), PropertiesStep([name],value)]
> {code}
> For some reason the {{OrderGlobalStep}} is moved to the end, after the
> {{DedupGlobalStep}}
> h2. g_V_playlist_paths
> {code:java}
> Scenario: g_V_playlist_paths
> Given the grateful graph
> And the traversal of
> """
> g.V().has("name", "Bob_Dylan").
> in("sungBy").order().by('name').as("a").
> repeat(__.out().order().by('name').simplePath().from("a")).
> until(__.out("writtenBy").has("name",
> "Johnny_Cash")).limit(1).as("b").
>
> repeat(__.out().order().by('name').as("c").simplePath().from("b").to("c")).
> until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
> path().from("a").unfold().
> project("song", "artists").
> by("name").
> by(__.coalesce(__.out("sungBy",
> "writtenBy").dedup().values("name").order(), __.constant("Unknown")).fold())
> """
> When iterated to list
> Then the result should be unordered
> | result |
> | m[{"song": "CHIMES OF FREEDOM", "artists": ["Bob_Dylan"]}] |
> | m[{"song": "QUEEN JANE", "artists": ["Unknown"]}] |
> | m[{"song": "ALTHEA", "artists": ["Garcia","Hunter"]}] |
> | m[{"song": "BIG RIVER", "artists": ["Johnny_Cash","Weir"]}] |
> | m[{"song": "HES GONE", "artists": ["Garcia","Hunter"]}] |
> | m[{"song": "CAUTION", "artists": ["Grateful_Dead"]}] |
> {code}
> This test also assumes `order`. Even though it has
> `__.out().order().by('name')` it is the path that needs to be ordered.
> Ordering on `name` is not good enough as there are duplicates.
> Here is an improved version.
> {code:java}
> List> result = g.traversal().V().has("name",
>
[jira] [Commented] (TINKERPOP-2816) Gherkin test issues for implementers
[
https://issues.apache.org/jira/browse/TINKERPOP-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646848#comment-17646848
]
ASF GitHub Bot commented on TINKERPOP-2816:
---
vkagamlyk merged PR #1893:
URL: https://github.com/apache/tinkerpop/pull/1893
> Gherkin test issues for implementers
>
>
> Key: TINKERPOP-2816
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2816
> Project: TinkerPop
> Issue Type: Bug
> Components: test-suite
>Affects Versions: 3.6.1
>Reporter: pieter martin
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
>
> Sqlg is encountering some issues when running the Gherkin feature tests.
> h2. g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> {code:java}
> Scenario:
> g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> Given the modern graph
> And the traversal of
> """
>
> g.V().repeat(__.out().repeat(__.out()).times(1)).times(1).limit(1).path().by("name")
> """
> When iterated next
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | ripple |
> {code}
> This test assumes an implicit order in the traversal. To fix the test we need
> to add in an {{order().by("name")}}
> {code:java}
> Scenario:
> g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name
> Given the modern graph
> And the traversal of
> """
> g.V().repeat(__.out().repeat(__.out().order().by("name",
> Order.desc)).times(1)).times(1).limit(1).path().by("name")
> """
> When iterated next
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | ripple |
> {code}
> h2. g_V_both_both_dedup_byXoutE_countX_name
> {code:java}
> Scenario: g_V_both_both_dedup_byXoutE_countX_name
> Given the modern graph
> And the traversal of
> """
> g.V().both().both().dedup().by(__.outE().count()).values("name")
> """
> When iterated to list
> Then the result should be unordered
> | result |
> | marko |
> | josh |
> | peter |
> | ripple |
> {code}
> This test assumes the order of {{{}V().both().both(){}}}.
> Unfortunately putting in an {{order().by("name")}} does not help. This is
> because of a second bug where {{TinkerPop}} is rewriting the steps
> incorrectly.
> {code:java}
> @Test
> public void testDedupSteps() {
> final TinkerGraph g = TinkerFactory.createModern();
> GraphTraversal traversal =
> g.traversal().V().both().both().order().by("name",
> Order.asc).dedup().by(__.outE().count()).values("name");
> traversal.hasNext();
> System.out.println(((DefaultGraphTraversal)traversal).getSteps());
> }
> {code}
> This produces,
> {code:java}
> [TinkerGraphStep(vertex,[]), VertexStep(BOTH,vertex), NoOpBarrierStep(2500),
> VertexStep(BOTH,vertex), DedupGlobalStep(null,[VertexStep(OUT,edge),
> CountGlobalStep]), OrderGlobalStep([[value([CoalesceStep([value(name),
> (null)])]), asc]]), PropertiesStep([name],value)]
> {code}
> For some reason the {{OrderGlobalStep}} is moved to the end, after the
> {{DedupGlobalStep}}
> h2. g_V_playlist_paths
> {code:java}
> Scenario: g_V_playlist_paths
> Given the grateful graph
> And the traversal of
> """
> g.V().has("name", "Bob_Dylan").
> in("sungBy").order().by('name').as("a").
> repeat(__.out().order().by('name').simplePath().from("a")).
> until(__.out("writtenBy").has("name",
> "Johnny_Cash")).limit(1).as("b").
>
> repeat(__.out().order().by('name').as("c").simplePath().from("b").to("c")).
> until(__.out("sungBy").has("name", "Grateful_Dead")).limit(1).
> path().from("a").unfold().
> project("song", "artists").
> by("name").
> by(__.coalesce(__.out("sungBy",
> "writtenBy").dedup().values("name").order(), __.constant("Unknown")).fold())
> """
> When iterated to list
> Then the result should be unordered
> | result |
> | m[{"song": "CHIMES OF FREEDOM", "artists": ["Bob_Dylan"]}] |
> | m[{"song": "QUEEN JANE", "artists": ["Unknown"]}] |
> | m[{"song": "ALTHEA", "artists": ["Garcia","Hunter"]}] |
> | m[{"song": "BIG RIVER", "artists": ["Johnny_Cash","Weir"]}] |
> | m[{"song": "HES GONE", "artists": ["Garcia","Hunter"]}] |
> | m[{"song": "CAUTION", "artists": ["Grateful_Dead"]}] |
> {code}
> This test also assumes `order`. Even though it has
> `__.out().order().by('name')` it is the path that needs to be ordered.
> Ordering on `name` is not good enough as there are duplicates.
> Here is an improved version.
> {code:java}
> List> result = g.traversal().V().has("name",
>
[jira] [Commented] (TINKERPOP-2819) Refactor SimpleSocketServer to be accessible to all GLV's
[ https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646846#comment-17646846 ] ASF GitHub Bot commented on TINKERPOP-2819: --- codecov-commenter commented on PR #1897: URL: https://github.com/apache/tinkerpop/pull/1897#issuecomment-1349825570 # [Codecov](https://codecov.io/gh/apache/tinkerpop/pull/1897?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#1897](https://codecov.io/gh/apache/tinkerpop/pull/1897?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (7318fc5) into [master](https://codecov.io/gh/apache/tinkerpop/commit/cc2ab6be55182fa96e26eb18fe1e47aa48274fd7?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (cc2ab6b) will **increase** coverage by `0.02%`. > The diff coverage is `80.00%`. ```diff @@ Coverage Diff @@ ## master#1897 +/- ## + Coverage 68.65% 68.68% +0.02% - Complexity 9130 9133 +3 Files 855 855 Lines 4110541105 Branches 5609 5609 + Hits 2821928231 +12 + Misses1090610892 -14 - Partials 1980 1982 +2 ``` | [Impacted Files](https://codecov.io/gh/apache/tinkerpop/pull/1897?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...op/gremlin/console/jsr223/DriverGremlinPlugin.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1jb25zb2xlL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS90aW5rZXJwb3AvZ3JlbWxpbi9jb25zb2xlL2pzcjIyMy9Ecml2ZXJHcmVtbGluUGx1Z2luLmphdmE=) | `0.00% <ø> (ø)` | | | [...p/gremlin/console/jsr223/DriverRemoteAcceptor.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1jb25zb2xlL3NyYy9tYWluL2phdmEvb3JnL2FwYWNoZS90aW5rZXJwb3AvZ3JlbWxpbi9jb25zb2xlL2pzcjIyMy9Ecml2ZXJSZW1vdGVBY2NlcHRvci5qYXZh) | `32.23% <ø> (ø)` | | | [...va/org/apache/tinkerpop/gremlin/driver/Client.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1kcml2ZXIvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3RpbmtlcnBvcC9ncmVtbGluL2RyaXZlci9DbGllbnQuamF2YQ==) | `55.55% <ø> (ø)` | | | [...a/org/apache/tinkerpop/gremlin/driver/Cluster.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1kcml2ZXIvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3RpbmtlcnBvcC9ncmVtbGluL2RyaXZlci9DbHVzdGVyLmphdmE=) | `76.52% <ø> (ø)` | | | [...rg/apache/tinkerpop/gremlin/driver/Connection.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1kcml2ZXIvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3RpbmtlcnBvcC9ncmVtbGluL2RyaXZlci9Db25uZWN0aW9uLmphdmE=) | `66.89% <ø> (+3.37%)` | :arrow_up: | | [...pache/tinkerpop/gremlin/driver/ConnectionPool.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1kcml2ZXIvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3RpbmtlcnBvcC9ncmVtbGluL2RyaXZlci9Db25uZWN0aW9uUG9vbC5qYXZh) | `31.85% <ø> (ø)` | | | [...a/org/apache/tinkerpop/gremlin/driver/Handler.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1kcml2ZXIvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3RpbmtlcnBvcC9ncmVtbGluL2RyaXZlci9IYW5kbGVyLmphdmE=) | `63.10% <ø> (ø)` | | | [...inkerpop/gremlin/driver/LoadBalancingStrategy.java](https://codecov.io/gh/apache/tinkerpop/pull/1897/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-Z3JlbWxpbi1kcml2ZXIvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL3RpbmtlcnBvcC9ncmVtbGluL2RyaXZlci9Mb2FkQmFsYW5jaW5nU3RyYXRlZ3kuamF2YQ==) | `56.66% <ø> (ø)` | | |
[jira] [Commented] (TINKERPOP-2819) Refactor SimpleSocketServer to be accessible to all GLV's
[ https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646835#comment-17646835 ] ASF GitHub Bot commented on TINKERPOP-2819: --- vkagamlyk commented on PR #1897: URL: https://github.com/apache/tinkerpop/pull/1897#issuecomment-1349786396 VOTE +1 > Refactor SimpleSocketServer to be accessible to all GLV's > - > > Key: TINKERPOP-2819 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2819 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Cole Greer >Priority: Major > > Currently there is a large gap in the testing capabilities of the java driver > compared to the other GLV's. Part of this gap is the java driver has > SimpleSocketServer which provides a useful platform to write tests which > require specific response behaviour from the server. Having such a tool for > all of the GLV's would allow for testing of many more potential failure cases > as well as taking a step towards standardizing the testing approach for all > GLV's. > This work can be divided into 2 main parts. > Part One: Decoupling SimpleSocketServer from the java driver. This is the > most disruptive part of the proposed changes. This has already been discussed > [here|https://lists.apache.org/thread/vd7w43xjzvc5rr0135gql9mxhdlcltr9] on > the dev list but I will summarize. To avoid having all the GLV's depending on > the java driver, SimpleSocketServer and it's related classes should be > extracted to a new module gremlin-tools/gremlin-socket-server. Unfortunately > the socket server still relies on the following classes in gremlin driver: > tinkerpop.gremlin.driver.message.* > tinkerpop.gremlin.driver.ser.* > tinkerpop.gremlin.driver.MessageSerializer > tinkerpop.gremlin.driver.Tokens > To avoid a cyclic dependency between gremlin-driver and > gremlin-socket-server. these classes should be moved to another new module > gremlin-util which will house any classes which are to be shared between the > driver and server. Moving these classes to a new module and package will > break import lines and will need to be left until 3.7. > The full list of classes moved into gremlin-util is as follows: > > ||Old Name/Location||New Name/Location|| > |org.apache.tinkerpop.gremlin.driver.MessageSerializer|org.apache.tinkerpop.gremlin.util.MessageSerializer| > |org.apache.tinkerpop.gremlin.driver.Tokens|org.apache.tinkerpop.gremlin.util.Tokens| > |org.apache.tinkerpop.gremlin.driver.message.RequestMessage|org.apache.tinkerpop.gremlin.util.message.RequestMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseMessage|org.apache.tinkerpop.gremlin.util.message.ResponseMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseResult|org.apache.tinkerpop.gremlin.util.message.ResponseResult| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatus|org.apache.tinkerpop.gremlin.util.message.ResponseStatus| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatusCode|org.apache.tinkerpop.gremlin.util.message.ResponseStatusCode| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractMessageSerializer|org.apache.tinkerpop.gremlin.util.ser.AbstractMessageSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1|org.apache.tinkerpop.gremlin.util.ser.GraphBinaryMessageSerializerV1| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV3d0| > |org.apache.tinkerpop.gremlin.driver.ser.MessageTextSerializer|org.apache.tinkerpop.gremlin.util.ser.MessageTextSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBuffer|org.apache.tinkerpop.gremlin.util.ser.NettyBuffer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBufferFactory|org.apache.tinkerpop.gremlin.util.ser.NettyBufferFactory| >
[jira] [Commented] (TINKERPOP-2836) Github actions do not run java driver integration tests/
[ https://issues.apache.org/jira/browse/TINKERPOP-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646820#comment-17646820 ] ASF GitHub Bot commented on TINKERPOP-2836: --- xiazcy closed pull request #1890: [Do Not Merge] TINKERPOP-2836 Demonstrate Github Actions Not Running Java Integration Tests URL: https://github.com/apache/tinkerpop/pull/1890 > Github actions do not run java driver integration tests/ > > > Key: TINKERPOP-2836 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2836 > Project: TinkerPop > Issue Type: Bug > Components: build-release >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Minor > > Currently the java driver integration tests are never run by the github > actions. Actions should be updated to run these tests. > > This [PR|https://github.com/apache/tinkerpop/pull/1890] demonstrates that the > integration tests are not being run currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2819) Refactor SimpleSocketServer to be accessible to all GLV's
[ https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646798#comment-17646798 ] ASF GitHub Bot commented on TINKERPOP-2819: --- xiazcy commented on PR #1897: URL: https://github.com/apache/tinkerpop/pull/1897#issuecomment-1349579062 Thanks Cole! VOTE +1 > Refactor SimpleSocketServer to be accessible to all GLV's > - > > Key: TINKERPOP-2819 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2819 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Cole Greer >Priority: Major > > Currently there is a large gap in the testing capabilities of the java driver > compared to the other GLV's. Part of this gap is the java driver has > SimpleSocketServer which provides a useful platform to write tests which > require specific response behaviour from the server. Having such a tool for > all of the GLV's would allow for testing of many more potential failure cases > as well as taking a step towards standardizing the testing approach for all > GLV's. > This work can be divided into 2 main parts. > Part One: Decoupling SimpleSocketServer from the java driver. This is the > most disruptive part of the proposed changes. This has already been discussed > [here|https://lists.apache.org/thread/vd7w43xjzvc5rr0135gql9mxhdlcltr9] on > the dev list but I will summarize. To avoid having all the GLV's depending on > the java driver, SimpleSocketServer and it's related classes should be > extracted to a new module gremlin-tools/gremlin-socket-server. Unfortunately > the socket server still relies on the following classes in gremlin driver: > tinkerpop.gremlin.driver.message.* > tinkerpop.gremlin.driver.ser.* > tinkerpop.gremlin.driver.MessageSerializer > tinkerpop.gremlin.driver.Tokens > To avoid a cyclic dependency between gremlin-driver and > gremlin-socket-server. these classes should be moved to another new module > gremlin-util which will house any classes which are to be shared between the > driver and server. Moving these classes to a new module and package will > break import lines and will need to be left until 3.7. > The full list of classes moved into gremlin-util is as follows: > > ||Old Name/Location||New Name/Location|| > |org.apache.tinkerpop.gremlin.driver.MessageSerializer|org.apache.tinkerpop.gremlin.util.MessageSerializer| > |org.apache.tinkerpop.gremlin.driver.Tokens|org.apache.tinkerpop.gremlin.util.Tokens| > |org.apache.tinkerpop.gremlin.driver.message.RequestMessage|org.apache.tinkerpop.gremlin.util.message.RequestMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseMessage|org.apache.tinkerpop.gremlin.util.message.ResponseMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseResult|org.apache.tinkerpop.gremlin.util.message.ResponseResult| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatus|org.apache.tinkerpop.gremlin.util.message.ResponseStatus| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatusCode|org.apache.tinkerpop.gremlin.util.message.ResponseStatusCode| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractMessageSerializer|org.apache.tinkerpop.gremlin.util.ser.AbstractMessageSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1|org.apache.tinkerpop.gremlin.util.ser.GraphBinaryMessageSerializerV1| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV3d0| > |org.apache.tinkerpop.gremlin.driver.ser.MessageTextSerializer|org.apache.tinkerpop.gremlin.util.ser.MessageTextSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBuffer|org.apache.tinkerpop.gremlin.util.ser.NettyBuffer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBufferFactory|org.apache.tinkerpop.gremlin.util.ser.NettyBufferFactory| >
[jira] [Commented] (TINKERPOP-2819) Refactor SimpleSocketServer to be accessible to all GLV's
[ https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646797#comment-17646797 ] ASF GitHub Bot commented on TINKERPOP-2819: --- spmallette commented on PR #1897: URL: https://github.com/apache/tinkerpop/pull/1897#issuecomment-1349578658 VOTE +1 > Refactor SimpleSocketServer to be accessible to all GLV's > - > > Key: TINKERPOP-2819 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2819 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Cole Greer >Priority: Major > > Currently there is a large gap in the testing capabilities of the java driver > compared to the other GLV's. Part of this gap is the java driver has > SimpleSocketServer which provides a useful platform to write tests which > require specific response behaviour from the server. Having such a tool for > all of the GLV's would allow for testing of many more potential failure cases > as well as taking a step towards standardizing the testing approach for all > GLV's. > This work can be divided into 2 main parts. > Part One: Decoupling SimpleSocketServer from the java driver. This is the > most disruptive part of the proposed changes. This has already been discussed > [here|https://lists.apache.org/thread/vd7w43xjzvc5rr0135gql9mxhdlcltr9] on > the dev list but I will summarize. To avoid having all the GLV's depending on > the java driver, SimpleSocketServer and it's related classes should be > extracted to a new module gremlin-tools/gremlin-socket-server. Unfortunately > the socket server still relies on the following classes in gremlin driver: > tinkerpop.gremlin.driver.message.* > tinkerpop.gremlin.driver.ser.* > tinkerpop.gremlin.driver.MessageSerializer > tinkerpop.gremlin.driver.Tokens > To avoid a cyclic dependency between gremlin-driver and > gremlin-socket-server. these classes should be moved to another new module > gremlin-util which will house any classes which are to be shared between the > driver and server. Moving these classes to a new module and package will > break import lines and will need to be left until 3.7. > The full list of classes moved into gremlin-util is as follows: > > ||Old Name/Location||New Name/Location|| > |org.apache.tinkerpop.gremlin.driver.MessageSerializer|org.apache.tinkerpop.gremlin.util.MessageSerializer| > |org.apache.tinkerpop.gremlin.driver.Tokens|org.apache.tinkerpop.gremlin.util.Tokens| > |org.apache.tinkerpop.gremlin.driver.message.RequestMessage|org.apache.tinkerpop.gremlin.util.message.RequestMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseMessage|org.apache.tinkerpop.gremlin.util.message.ResponseMessage| > |org.apache.tinkerpop.gremlin.driver.message.ResponseResult|org.apache.tinkerpop.gremlin.util.message.ResponseResult| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatus|org.apache.tinkerpop.gremlin.util.message.ResponseStatus| > |org.apache.tinkerpop.gremlin.driver.message.ResponseStatusCode|org.apache.tinkerpop.gremlin.util.message.ResponseStatusCode| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.AbstractGraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.AbstractMessageSerializer|org.apache.tinkerpop.gremlin.util.ser.AbstractMessageSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1|org.apache.tinkerpop.gremlin.util.ser.GraphBinaryMessageSerializerV1| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerGremlinV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV1d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV2d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV2d0| > |org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0|org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV3d0| > |org.apache.tinkerpop.gremlin.driver.ser.MessageTextSerializer|org.apache.tinkerpop.gremlin.util.ser.MessageTextSerializer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBuffer|org.apache.tinkerpop.gremlin.util.ser.NettyBuffer| > |org.apache.tinkerpop.gremlin.driver.ser.NettyBufferFactory|org.apache.tinkerpop.gremlin.util.ser.NettyBufferFactory| >
[jira] [Commented] (TINKERPOP-2373) Bump to Groovy 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646776#comment-17646776 ] Stephen Mallette commented on TINKERPOP-2373: - More problems - the performance issue are now showing on the 2.5.x line. TinkerPop fails to build with 2.5.16 for some and then on 2.5.17 the performance problems appear. We're stuck at 2.5.15 at this point. https://github.com/apache/tinkerpop/commit/f4c5bd727e570ef6e258b91a9ea69fed2a0a93bb > Bump to Groovy 3.0 > -- > > Key: TINKERPOP-2373 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2373 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.5.0 >Reporter: Stephen Mallette >Priority: Major > > Groovy 3.0 has been out for a while now and has done several patch releases. > Time to upgrade on 3.5.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2834) CloneVertexProgram optimization on SparkGraphComputer
[ https://issues.apache.org/jira/browse/TINKERPOP-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette closed TINKERPOP-2834. --- Fix Version/s: 3.7.0 3.6.2 3.5.5 Assignee: Stephen Mallette Resolution: Done > CloneVertexProgram optimization on SparkGraphComputer > - > > Key: TINKERPOP-2834 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2834 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.5.4 >Reporter: Redriver >Assignee: Stephen Mallette >Priority: Major > Fix For: 3.7.0, 3.6.2, 3.5.5 > > > The CloneVertexProgram does nothing in its execute() method, but in > SparkGraphComputer it has to process as standard GraphComputer semantics, > which takes many unnecessary computation. In fact, registering a special > SparkVertexProgramInterceptor with empty apply() can improve the overall > performance a lot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2834) CloneVertexProgram optimization on SparkGraphComputer
[ https://issues.apache.org/jira/browse/TINKERPOP-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646601#comment-17646601 ] ASF GitHub Bot commented on TINKERPOP-2834: --- spmallette merged PR #1885: URL: https://github.com/apache/tinkerpop/pull/1885 > CloneVertexProgram optimization on SparkGraphComputer > - > > Key: TINKERPOP-2834 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2834 > Project: TinkerPop > Issue Type: Improvement > Components: hadoop >Affects Versions: 3.5.4 >Reporter: Redriver >Priority: Major > > The CloneVertexProgram does nothing in its execute() method, but in > SparkGraphComputer it has to process as standard GraphComputer semantics, > which takes many unnecessary computation. In fact, registering a special > SparkVertexProgramInterceptor with empty apply() can improve the overall > performance a lot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Properties on elements
I'm ok with all of Dave's suggestions. There was also a consideration for
backward compatibility to getting a ReferenceElement with this mechanism,
but given use of Token, perhaps we drop that too. Folks would need to
continue to use withStrategies(ReferenceElementStrategy) to keep getting
references if they wanted that.
On Mon, Dec 12, 2022 at 8:38 PM David Bechberger
wrote:
> I like using the with() approach over a strategy, as I think it will be
> more user-friendly and discoverable for customers.
>
> I think my main comments are:
>
> 1) Let's keep it simple to start with and just allow "All" or "Tokens".
> Custom will lead us down a rabbit hole of how far we want to go with allow
> different options per label etc. We can release with a simple v1 and
> gather feedback from users on how/if they need more granularity.
> Meanwhile, customers can still get this behavior through the use of the
> current steps such as valueMap()
> 2) I think we should leverage the same tokens as we do with valueMap() to
> help show that they are connected.
> 3) "detach" is not a word that most people would associate with returning
> properties. I suggest something like "materializeProperties"
>
> Combining these together we get the following as the proposed syntax:
> g.with(‘materializeProperties’, T.tokens).V()
> g.with(‘materializeProperties’, T.all).V()
>
> As far as the default goes, no matter which way we choose, someone will not
> be happy. If we choose to default to "tokens", then we are in the same
> behavior as currently, which benefits existing applications while making
> new applications unhappy. If we choose to default to "all", then this may
> be a breaking change for applications but will smooth the on ramp for new
> customers as the current behavior is unexpected. Between these two, I
> would vote for going with the breaking behavior to simplify the new
> developer experience. While it may break some users, I have not often seen
> users returning the elements, as it is usually a combination of just an id
> or label explicitly or those tokens with all or a subset of properties.
>
> Another advantage to defaulting to returning all the materialized values is
> that this will benefit many visualization tools that need to manually
> request this information today to render correctly.
>
> Thoughts?
>
> Dave
>
> On Thu, Dec 8, 2022 at 7:41 AM Stephen Mallette
> wrote:
>
> > i was trying to summarize the decisions we're trying to make on this
> issue
> > and it occurred to me that the problems we're facing here raise some
> > fundamental questions about the original direction i'd proposed. i long
> ago
> > chose a strategy approach to doing this, mostly because we have some
> > history of doing that with HaltedTraverserStrategy and
> > ReferenceElementStrategy, but I can't help wondering now if that pattern
> > should be followed. It's troubling me that DetachStrategy,
> > ReferenceElementStrategy , etc. really don't have any relevance to
> embedded
> > use cases (aside from the very specific case of OLAP with
> > HaltedTraverserStrategy). They are really just mechanisms to help control
> > serialization costs and as such are more request/response oriented as
> > opposed to traversal oriented. If we treated it that way maybe some of
> > these hard decisions would go away.
> >
> > I was thinking that maybe we could add “detachment” to RequestOptions and
> > use the same syntax already established for DetachStrategy in there.
> Hooked
> > up properly this would allow something like:
> >
> > g.with(‘detach’, Detach.custom("name", "age")).V()
> >
> > On the server, we’d then just have to extract that Detach from the
> > RequestMessage and apply it on serialization as needed.
> >
> > I see several advantages with this revised design:
> >
> > 1. No more worries about the extra step in profile() - which is even a
> > problem now in ReferenceElementStrategy
> > 2. This works as easily for scripts as it does for bytecode
> > 3. We don’t mix this capability up with embedded use cases, so there’s no
> > confusion about when/why you use this.
> >
> > Going further with the above Gremlin syntax, maybe the argument to with()
> > should be like:
> >
> > g.with(‘detach’, "ALL").V()
> > g.with(‘detach’, "NONE").V()
> > g.with(‘detach’, ["name", "age"]).V() // a list implies CUSTOM
> >
> > The advantage here is that we don’t have to change the grammar in
> > gremlin-language and the serializers don’t need to change at all. We
> could
> > retain the Detach.custom("name", "age") or similar syntax for Java/Groovy
> > and come up with similar sugar for the other languages.
> >
> > I think that still leaves the question of what the default should be on
> the
> > server for 3.7.0 - perhaps we come back to that once there is feedback on
> > this design revision.
> >
> >
> >
> > On Tue, Nov 22, 2022 at 7:06 AM Stephen Mallette
> > wrote:
> >
> > > > My proposal is to always have some detachment strategy in server
> > > configuration
