Repository: tinkerpop
Updated Branches:
  refs/heads/master fa6f51887 -> efcff1613


reviewed upgrade docs and found a typo and a mess up. CTR.


Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/efcff161
Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/efcff161
Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/efcff161

Branch: refs/heads/master
Commit: efcff1613c5250b9c3bf9bcffd00ca90a5b7d989
Parents: fa6f518
Author: Marko A. Rodriguez <okramma...@gmail.com>
Authored: Mon Oct 17 07:34:28 2016 -0600
Committer: Marko A. Rodriguez <okramma...@gmail.com>
Committed: Mon Oct 17 07:34:44 2016 -0600

----------------------------------------------------------------------
 docs/src/upgrade/release-3.2.x-incubating.asciidoc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/efcff161/docs/src/upgrade/release-3.2.x-incubating.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/upgrade/release-3.2.x-incubating.asciidoc 
b/docs/src/upgrade/release-3.2.x-incubating.asciidoc
index a89fe86..afbfa7e 100644
--- a/docs/src/upgrade/release-3.2.x-incubating.asciidoc
+++ b/docs/src/upgrade/release-3.2.x-incubating.asciidoc
@@ -185,7 +185,7 @@ g.V().out().barrier().V().barrier().has(a)
 Given that `LazyBarrierStrategy` is an `OptimizationStrategy`, it comes before 
`ProviderOptimizationStrategies`.
 Thus, if the provider's `XXXGraphStepStrategy` simply walks from the second 
`V()` looking for `has()`-only, it will not
 be able to pull in the `has()` cause the `barrier()` blocks it. Please see the 
updates to `TinkerGraphStepStrategy` and
-how it acknowledges `NoOpBarrierSteps` (i.e. `barrier()``) skipping over them 
and “left”-propagating labels to the
+how it acknowledges `NoOpBarrierSteps` (i.e. `barrier()`) skipping over them 
and “left”-propagating labels to the
 previous step.
 
 See: link:https://issues.apache.org/jira/browse/TINKERPOP-1488[TINKERPOP-1488]
@@ -291,8 +291,8 @@ 
link:https://issues.apache.org/jira/browse/TINKERPOP-844[TINKERPOP-844]
 ConnectiveP Nesting Inlined
 +++++++++++++++++++++++++++
 
-There was a bug in `ConnectiveP` (`AndP`/`OrP`), where 
`eq(1).and(eq(2).and(eq(3)))` was `OrP(eq(1),AndP(eq(2),eq(3)))`
-instead of unnested/inlined as `OrP(eq(1),eq(2),eq(3))`. Likewise, for `AndP`. 
If a provider was leveraging `ConnectiveP`
+There was a bug in `ConnectiveP` (`AndP`/`OrP`), where 
`eq(1).and(eq(2).and(eq(3)))` was `AndP(eq(1),AndP(eq(2),eq(3)))`
+instead of unnested/inlined as `AndP(eq(1),eq(2),eq(3))`. Likewise, for `OrP`. 
If a provider was leveraging `ConnectiveP`
 predicates for their custom steps (e.g. graph- or vertex-centric index 
lookups), then they should be aware of the inlining
 and can simplify any and/or-tree walking code in their respective 
`ProviderOptimizationStrategy`.
 

Reply via email to