[jira] [Commented] (TINKERPOP-1967) Add a connectedComponent() step
[ https://issues.apache.org/jira/browse/TINKERPOP-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511602#comment-16511602 ] ASF GitHub Bot commented on TINKERPOP-1967: --- Github user vtslab closed the pull request at: https://github.com/apache/tinkerpop/pull/875 > Add a connectedComponent() step > --- > > Key: TINKERPOP-1967 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1967 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.3.3 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Fix For: 3.4.0 > > > Given TINKERPOP-1852 we should probably just simplify and improve performance > of connected component identification. Implementing this will involved the > creation of {{ConnectedComponentVertexProgram}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop pull request #875: TINKERPOP-1967 Add a connectedComponent() step ...
Github user vtslab closed the pull request at: https://github.com/apache/tinkerpop/pull/875 ---
[jira] [Commented] (TINKERPOP-1967) Add a connectedComponent() step
[ https://issues.apache.org/jira/browse/TINKERPOP-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511601#comment-16511601 ] ASF GitHub Bot commented on TINKERPOP-1967: --- Github user vtslab commented on the issue: https://github.com/apache/tinkerpop/pull/875 PR is malformed due to problems in master. I close this one and prepare a new PR with the same commits. > Add a connectedComponent() step > --- > > Key: TINKERPOP-1967 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1967 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.3.3 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Fix For: 3.4.0 > > > Given TINKERPOP-1852 we should probably just simplify and improve performance > of connected component identification. Implementing this will involved the > creation of {{ConnectedComponentVertexProgram}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #875: TINKERPOP-1967 Add a connectedComponent() step - vtsla...
Github user vtslab commented on the issue: https://github.com/apache/tinkerpop/pull/875 PR is malformed due to problems in master. I close this one and prepare a new PR with the same commits. ---
[jira] [Commented] (TINKERPOP-1967) Add a connectedComponent() step
[ https://issues.apache.org/jira/browse/TINKERPOP-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511646#comment-16511646 ] ASF GitHub Bot commented on TINKERPOP-1967: --- GitHub user vtslab opened a pull request: https://github.com/apache/tinkerpop/pull/877 Tinkerpop 1967 Add a connectedComponent() step - vtslab contribution2 This merges the new OLAP step into a corrected version of the old recipe. I did not adapt the release-update file, which is no longer consistent with the sutiation (leave that to you). I made a comment in the TINKERPOP-1967 branch proper about the gremlin-console import section. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vtslab/incubator-tinkerpop TINKERPOP-1967-vtslab2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/877.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #877 commit 28d4b02660f3f5c682538acaf4768218d9a8b40a Author: HadoopMarc Date: 2018-05-21T12:03:54Z Merged vtslab recipe for connected components commit b087822708707013f7f0cd3b5abaf6d0f574a72e Author: HadoopMarc Date: 2018-06-10T13:17:17Z Extended the connected-components recipe > Add a connectedComponent() step > --- > > Key: TINKERPOP-1967 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1967 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.3.3 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Fix For: 3.4.0 > > > Given TINKERPOP-1852 we should probably just simplify and improve performance > of connected component identification. Implementing this will involved the > creation of {{ConnectedComponentVertexProgram}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop pull request #877: Tinkerpop 1967 Add a connectedComponent() step ...
GitHub user vtslab opened a pull request: https://github.com/apache/tinkerpop/pull/877 Tinkerpop 1967 Add a connectedComponent() step - vtslab contribution2 This merges the new OLAP step into a corrected version of the old recipe. I did not adapt the release-update file, which is no longer consistent with the sutiation (leave that to you). I made a comment in the TINKERPOP-1967 branch proper about the gremlin-console import section. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vtslab/incubator-tinkerpop TINKERPOP-1967-vtslab2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/877.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #877 commit 28d4b02660f3f5c682538acaf4768218d9a8b40a Author: HadoopMarc Date: 2018-05-21T12:03:54Z Merged vtslab recipe for connected components commit b087822708707013f7f0cd3b5abaf6d0f574a72e Author: HadoopMarc Date: 2018-06-10T13:17:17Z Extended the connected-components recipe ---
[jira] [Closed] (TINKERPOP-1831) Refactor EventStrategy
[ https://issues.apache.org/jira/browse/TINKERPOP-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1831. --- Resolution: Done Ended up with a pretty straightforward fix via CTR for this: https://github.com/apache/tinkerpop/commit/fc866751e11768666ed347f772d86d888a2dec16 > Refactor EventStrategy > --- > > Key: TINKERPOP-1831 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1831 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.2.6 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: breaking > Fix For: 3.4.0 > > > {{EventStrategy}} has a few issues that could be smoothed out, but not > without an allowance for breaking change in the API: > * For the creation of new properties, an empty detached property is created > to represent it - now that detachment is configurable, that doesn't always > make sense. For example, if you configured for reference detachment then you > would probably want a {{ReferenceProperty}} instead. Not sure how this should > be resolved, but it probably needs a change to the eventing API itself > * Detachment is configured a bit strangely with the use of {{null}} and > passing classes for the appropriate detachment factorieswould be nicer to > have an interface to represent this stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (TINKERPOP-1831) Refactor EventStrategy
[ https://issues.apache.org/jira/browse/TINKERPOP-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette reopened TINKERPOP-1831: - I've realized that I fumbled this implementation as soon as I tried adapting the code to an implementation I have. Using "empty" to signify "new" doesn't work because you lose the key that was being changed and all you get is the value. Need to fix that somehow. > Refactor EventStrategy > --- > > Key: TINKERPOP-1831 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1831 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.2.6 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: breaking > Fix For: 3.4.0 > > > {{EventStrategy}} has a few issues that could be smoothed out, but not > without an allowance for breaking change in the API: > * For the creation of new properties, an empty detached property is created > to represent it - now that detachment is configurable, that doesn't always > make sense. For example, if you configured for reference detachment then you > would probably want a {{ReferenceProperty}} instead. Not sure how this should > be resolved, but it probably needs a change to the eventing API itself > * Detachment is configured a bit strangely with the use of {{null}} and > passing classes for the appropriate detachment factorieswould be nicer to > have an interface to represent this stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-967) Support nested-repeat() structures
[ https://issues.apache.org/jira/browse/TINKERPOP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510966#comment-16510966 ] ASF GitHub Bot commented on TINKERPOP-967: -- Github user GCHQResearcher1337 commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/876#discussion_r195046349 --- Diff: gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/RepeatTest.java --- @@ -386,5 +456,26 @@ public void g_V_hasXname_markoX_repeatXoutE_inV_simplePathX_untilXhasXname_rippl public Traversal get_g_V_hasXloop_name_loopX_repeatXinX_timesX5X_path_by_name() { return g.V().has("loops","name","loop").repeat(__.in()).times(5).path().by("name"); } + +@Override +public Traversal get_g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name() { +// NB We need to prevent the RepeatUnrollStrategy from applying to properly exercise this test as this traversal can be simplified --- End diff -- Thanks @spmallette I wanted to do something like this but hadn't spotted these tests. While writing some tests I've noticed that when RepeatUnrollStrategy is applied from the inside out, adding a barrier step onto the end: repeat(a.repeat(b).times(1)).times(1) -> repeat(a.b.barrier).times(1) repeat(a.b.barrier).times(1) -> a.b.barrier.barrier eg ``` gremlin> g.V().repeat(out().repeat(out()).times(1)).times(1).explain() ==>Traversal Explanation === Original Traversal [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] ConnectiveStrategy [D] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] MatchPredicateStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] FilterRankingStrategy[O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] InlineFilterStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] RepeatUnrollStrategy [O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] CountStrategy[O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] PathRetractionStrategy [O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] LazyBarrierStrategy [O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] TinkerGraphCountStrategy [P] [GraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] ProfileStrategy [F] [TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] Final Traversal[TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex),
[GitHub] tinkerpop pull request #876: TINKERPOP-967 Support nested-repeat() structure...
Github user GCHQResearcher1337 commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/876#discussion_r195046349 --- Diff: gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/RepeatTest.java --- @@ -386,5 +456,26 @@ public void g_V_hasXname_markoX_repeatXoutE_inV_simplePathX_untilXhasXname_rippl public Traversal get_g_V_hasXloop_name_loopX_repeatXinX_timesX5X_path_by_name() { return g.V().has("loops","name","loop").repeat(__.in()).times(5).path().by("name"); } + +@Override +public Traversal get_g_V_repeatXout_repeatXoutX_timesX1XX_timesX1X_limitX1X_path_by_name() { +// NB We need to prevent the RepeatUnrollStrategy from applying to properly exercise this test as this traversal can be simplified --- End diff -- Thanks @spmallette I wanted to do something like this but hadn't spotted these tests. While writing some tests I've noticed that when RepeatUnrollStrategy is applied from the inside out, adding a barrier step onto the end: repeat(a.repeat(b).times(1)).times(1) -> repeat(a.b.barrier).times(1) repeat(a.b.barrier).times(1) -> a.b.barrier.barrier eg ``` gremlin> g.V().repeat(out().repeat(out()).times(1)).times(1).explain() ==>Traversal Explanation === Original Traversal [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] ConnectiveStrategy [D] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] MatchPredicateStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] FilterRankingStrategy[O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] InlineFilterStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] IncidentToAdjacentStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] AdjacentToIncidentStrategy [O] [GraphStep(vertex,[]), RepeatStep([VertexStep(OUT,vertex), RepeatStep([VertexStep(OUT,vertex), RepeatEndStep],until(loops(1)),emit(false)), RepeatEndStep],until(loops(1)),emit(false))] RepeatUnrollStrategy [O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] CountStrategy[O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] PathRetractionStrategy [O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] LazyBarrierStrategy [O] [GraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] TinkerGraphCountStrategy [P] [GraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] TinkerGraphStepStrategy [P] [TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] ProfileStrategy [F] [TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] StandardVerificationStrategy [V] [TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] Final Traversal[TinkerGraphStep(vertex,[]), VertexStep(OUT,vertex), NoOpBarrierStep(2500), VertexStep(OUT,vertex), NoOpBarrierStep(2500), NoOpBarrierStep(2500)] ``` Do you think it's ok to leave multiple barrier steps at the end? I could add an extra check that we aren't inserting a barrier after a barrier here - but this could interfere with a
[jira] [Closed] (TINKERPOP-1518) Provide a way for providers to expose static Graph.Features to tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1518. --- Resolution: Implemented > Provide a way for providers to expose static Graph.Features to tests > > > Key: TINKERPOP-1518 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1518 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Major > Fix For: 3.4.0 > > > Determine if there's a way to cache graph features to avoid having to load a > {{Graph}} instance for a test. That could save some test cycles for graphs > that dont' support a test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1831) Refactor EventStrategy
[ https://issues.apache.org/jira/browse/TINKERPOP-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510884#comment-16510884 ] ASF GitHub Bot commented on TINKERPOP-1831: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/872 > Refactor EventStrategy > --- > > Key: TINKERPOP-1831 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1831 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.2.6 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: breaking > Fix For: 3.4.0 > > > {{EventStrategy}} has a few issues that could be smoothed out, but not > without an allowance for breaking change in the API: > * For the creation of new properties, an empty detached property is created > to represent it - now that detachment is configurable, that doesn't always > make sense. For example, if you configured for reference detachment then you > would probably want a {{ReferenceProperty}} instead. Not sure how this should > be resolved, but it probably needs a change to the eventing API itself > * Detachment is configured a bit strangely with the use of {{null}} and > passing classes for the appropriate detachment factorieswould be nicer to > have an interface to represent this stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TINKERPOP-1831) Refactor EventStrategy
[ https://issues.apache.org/jira/browse/TINKERPOP-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1831. --- Resolution: Implemented > Refactor EventStrategy > --- > > Key: TINKERPOP-1831 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1831 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.2.6 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: breaking > Fix For: 3.4.0 > > > {{EventStrategy}} has a few issues that could be smoothed out, but not > without an allowance for breaking change in the API: > * For the creation of new properties, an empty detached property is created > to represent it - now that detachment is configurable, that doesn't always > make sense. For example, if you configured for reference detachment then you > would probably want a {{ReferenceProperty}} instead. Not sure how this should > be resolved, but it probably needs a change to the eventing API itself > * Detachment is configured a bit strangely with the use of {{null}} and > passing classes for the appropriate detachment factorieswould be nicer to > have an interface to represent this stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop pull request #872: TINKERPOP-1831 Refactored EventStrategy
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/872 ---
[jira] [Commented] (TINKERPOP-1518) Provide a way for providers to expose static Graph.Features to tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510876#comment-16510876 ] ASF GitHub Bot commented on TINKERPOP-1518: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/873 > Provide a way for providers to expose static Graph.Features to tests > > > Key: TINKERPOP-1518 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1518 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Major > Fix For: 3.4.0 > > > Determine if there's a way to cache graph features to avoid having to load a > {{Graph}} instance for a test. That could save some test cycles for graphs > that dont' support a test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop pull request #873: TINKERPOP-1518 Cache Graph.Features for tests
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/873 ---
[GitHub] tinkerpop issue #872: TINKERPOP-1831 Refactored EventStrategy
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/872 VOTE +1 ---
[jira] [Commented] (TINKERPOP-1831) Refactor EventStrategy
[ https://issues.apache.org/jira/browse/TINKERPOP-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510829#comment-16510829 ] ASF GitHub Bot commented on TINKERPOP-1831: --- Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/872 VOTE +1 > Refactor EventStrategy > --- > > Key: TINKERPOP-1831 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1831 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.2.6 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: breaking > Fix For: 3.4.0 > > > {{EventStrategy}} has a few issues that could be smoothed out, but not > without an allowance for breaking change in the API: > * For the creation of new properties, an empty detached property is created > to represent it - now that detachment is configurable, that doesn't always > make sense. For example, if you configured for reference detachment then you > would probably want a {{ReferenceProperty}} instead. Not sure how this should > be resolved, but it probably needs a change to the eventing API itself > * Detachment is configured a bit strangely with the use of {{null}} and > passing classes for the appropriate detachment factorieswould be nicer to > have an interface to represent this stuff. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1518) Provide a way for providers to expose static Graph.Features to tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510822#comment-16510822 ] ASF GitHub Bot commented on TINKERPOP-1518: --- Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/873 Nice doc on the new method, VOTE +1 > Provide a way for providers to expose static Graph.Features to tests > > > Key: TINKERPOP-1518 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1518 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.2 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Major > Fix For: 3.4.0 > > > Determine if there's a way to cache graph features to avoid having to load a > {{Graph}} instance for a test. That could save some test cycles for graphs > that dont' support a test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #873: TINKERPOP-1518 Cache Graph.Features for tests
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/873 Nice doc on the new method, VOTE +1 ---