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