[jira] [Commented] (TINKERPOP-1437) Add tests for dedup(Scope) in DedupTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497517#comment-15497517
 ] 

ASF GitHub Bot commented on TINKERPOP-1437:
---

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/426#discussion_r79258124
  
--- Diff: 
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/DedupTest.java
 ---
@@ -241,6 +279,16 @@ public void g_V_both_both_dedup_byXoutE_countX_name() {
 
 public static class Traversals extends DedupTest {
 @Override
+public Traversal 
get_g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold() {
+return 
g.V().out().in().values("name").fold().dedup(Scope.local).unfold();
+}
+
+@Override
+public Traversal> 
get_g_V_out_in_asXxX_in_asXyX_selectXx_yX_byXnameX_fold_dedupXlocal_x_yX_unfold()
 {
--- End diff --

You named the method wrong. Should be `get_g_V_out_asXxX_in_asXyX.`


> Add tests for dedup(Scope) in DedupTest
> ---
>
> Key: TINKERPOP-1437
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1437
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.1.4
>Reporter: stephen mallette
>Priority: Minor
>
> There are no tests in the test suite that exercise:
> {code}
> public default GraphTraversal dedup(final Scope scope, final String... 
> dedupLabels) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #426: TINKERPOP-1437 Added tests for dedup(Scope,String...) ...

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/426
  
Made a few comments to ensure your test code is consistent with the others. 
Besides minor cosmetics -- VOTE +1.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1437) Add tests for dedup(Scope) in DedupTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497516#comment-15497516
 ] 

ASF GitHub Bot commented on TINKERPOP-1437:
---

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/426#discussion_r79258468
  
--- Diff: 
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/DedupTest.java
 ---
@@ -73,6 +77,40 @@
 
 public abstract Traversal 
get_g_V_both_both_dedup_byXoutE_countX_name();
 
+public abstract Traversal 
get_g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold();
+
+public abstract Traversal> 
get_g_V_out_in_asXxX_in_asXyX_selectXx_yX_byXnameX_fold_dedupXlocal_x_yX_unfold();
+
+@Test
+@LoadGraphWith(MODERN)
+public void g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold() {
+final Traversal traversal = 
get_g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold();
+final List names = traversal.toList();
+assertEquals(3, names.size());
+assertThat(names, containsInAnyOrder("marko", "josh", "peter"));
--- End diff --

Note we have `checkResults()`... e.g.

```
@Test
@LoadGraphWith(MODERN)
public void g_V_whereXnotXoutXcreatedXXX_name() {
final Traversal traversal = 
get_g_V_whereXnotXoutXcreatedXXX_name();
printTraversalForm(traversal);
checkResults(Arrays.asList("vadas", "lop", "ripple"), traversal);
}
```


> Add tests for dedup(Scope) in DedupTest
> ---
>
> Key: TINKERPOP-1437
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1437
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.1.4
>Reporter: stephen mallette
>Priority: Minor
>
> There are no tests in the test suite that exercise:
> {code}
> public default GraphTraversal dedup(final Scope scope, final String... 
> dedupLabels) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #426: TINKERPOP-1437 Added tests for dedup(Scope,Stri...

[okram]

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/426#discussion_r79258124
  
--- Diff: 
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/DedupTest.java
 ---
@@ -241,6 +279,16 @@ public void g_V_both_both_dedup_byXoutE_countX_name() {
 
 public static class Traversals extends DedupTest {
 @Override
+public Traversal 
get_g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold() {
+return 
g.V().out().in().values("name").fold().dedup(Scope.local).unfold();
+}
+
+@Override
+public Traversal> 
get_g_V_out_in_asXxX_in_asXyX_selectXx_yX_byXnameX_fold_dedupXlocal_x_yX_unfold()
 {
--- End diff --

You named the method wrong. Should be `get_g_V_out_asXxX_in_asXyX.`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #426: TINKERPOP-1437 Added tests for dedup(Scope,Stri...

[okram]

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/426#discussion_r79258319
  
--- Diff: 
gremlin-test/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/DedupTest.java
 ---
@@ -73,6 +77,40 @@
 
 public abstract Traversal 
get_g_V_both_both_dedup_byXoutE_countX_name();
 
+public abstract Traversal 
get_g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold();
+
+public abstract Traversal> 
get_g_V_out_in_asXxX_in_asXyX_selectXx_yX_byXnameX_fold_dedupXlocal_x_yX_unfold();
+
+@Test
+@LoadGraphWith(MODERN)
+public void g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold() {
+final Traversal traversal = 
get_g_V_out_in_valuesXnameX_fold_dedupXlocalX_unfold();
+final List names = traversal.toList();
+assertEquals(3, names.size());
+assertThat(names, containsInAnyOrder("marko", "josh", "peter"));
+}
+
+@Test
+@LoadGraphWith(MODERN)
+public void 
g_V_out_in_asXxX_in_asXyX_selectXx_yX_byXnameX_fold_dedupXlocal_x_yX_unfold() {
--- End diff --

This has a bad method name --- see my other comment and then fix it here 
too.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-932) Add ability to cancel script execution associated with a Gremlin Server Session

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497302#comment-15497302
 ] 

stephen mallette commented on TINKERPOP-932:


I sense that barring some obscene change to TinkerPop's transactional model, we 
won't get much closer to a solution for this than what was done on 
TINKERPOP-1442. The only additional change left that I think I could do is to 
implement a "force" option on a close request that would just interrupt the 
thread running the session and orphan the transactions leaving it up to the 
graph implementation to sort out what to do with them. In a sense, a "force" 
might be better than awaiting a timeout (e.g. you have a long/infinite timeout 
for an OLAP job). Of course, an "interrupt" is merely a suggestion to stop the 
thread in the session so, that might not even doing anything at the end of the 
day depending on the script. 

If there are no other ideas on this, I will try to implement a "force" option 
in the manner I just described. If for some reason that isn't possible then I 
will just close this barring no new ideas.

> Add ability to cancel script execution associated with a Gremlin Server 
> Session 
> 
>
> Key: TINKERPOP-932
> URL: https://issues.apache.org/jira/browse/TINKERPOP-932
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: Zachary Kurey
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> Currently with a {{SessionedClient}} there is no way to cancel a long running 
> script and the client has to depend on Gremlin Server side configured 
> timeouts before they can execute another script associated with the same 
> session id.
> There is a way we can forcefully close a session from the client side, or 
> just close the entire Gremlin client.  But it would be useful for client side 
> applications to be able to cancel script execution, have its intermediate 
> effects rolled back, and be able to continue interacting with the session 
> without losing session variable state maintained on the Gremlin server side.
> Unsure where this should live at an API level, since canceling by session id 
> isn't relevant for all {{Client}} implementations.  If somehow when the 
> {{CompletableFuture}} returned by {{Client.submitAsync}} could do 
> this when the {{Future}} is canceled, that would be a nice way to bridge 
> implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1031) Map URL routes to static method execution in REST API

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1031.
---
Resolution: Won't Fix

I don't think this is a good idea anymore. We don't really have a REST API to 
speak of and this might not be a good thing for TinkerPop to have to maintain. 
As I doubt that this ever saw any discussion at all on the dev list, I'm just 
going to close this as something that wont' be done.

> Map URL routes to static method execution in REST API
> -
>
> Key: TINKERPOP-1031
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1031
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Priority: Minor
>
> So a request like this:
> http://localhost:8182/Ping/ping?args=pong
> would call a static method in bound to the Script Engine as 
> {{Ping.ping("pong")}}.  Sandboxing could provide security - or perhaps some 
> other method.  This one needs more thought - just an idea.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1095) Create a custom ScriptContext

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1095:

Summary: Create a custom ScriptContext  (was: Determine if a custom 
ScriptContext is required)

> Create a custom ScriptContext
> -
>
> Key: TINKERPOP-1095
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1095
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.1.0-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.3
>
>
> The current {{ScriptContext}} in use with the {{ScriptEngine}} is the 
> {{SimpleScriptContext}}.  It doesnt' allow for additional scopes which might 
> be useful when dealing with the {{ScriptEnginePluginAcceptor}} which allows 
> plugins to inject "global" bindings into the a {{ScriptEngine}} instance 
> (e.g. the "hdfs" object with the hadoop plugin).
> We currently inject this into the {{GLOBAL_SCOPE}} of the {{ScriptEngine}} 
> which at the moment doesn't seem to conflict with anything, but I wonder if 
> more separation is required.
> Another alternative would be to manage these types of "globals" with new 
> methods on the {{DependencyManager}} interface.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1437) Add tests for dedup(Scope) in DedupTest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497263#comment-15497263
 ] 

ASF GitHub Bot commented on TINKERPOP-1437:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/426

TINKERPOP-1437 Added tests for dedup(Scope,String...) overload in DedupTest

https://issues.apache.org/jira/browse/TINKERPOP-1437

Pretty simple - just added a couple of tests - but didn't CTR as I'd feel 
better with a couple of extra eyes on this as we've had bad tests slip into the 
suite in the past.  

Runs nicely with `mvn clean install` - doing a `docker/build.sh -t -i -n` 
now. If anything bad happens I'll post back here.

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1437

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/426.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 #426


commit 9666bb3dc2f593b66095b3e764678ccfc35630a5
Author: Stephen Mallette 
Date:   2016-09-16T20:17:33Z

Added tests for dedup(Scope,String...) overload in DedupTest




> Add tests for dedup(Scope) in DedupTest
> ---
>
> Key: TINKERPOP-1437
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1437
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.1.4
>Reporter: stephen mallette
>Priority: Minor
>
> There are no tests in the test suite that exercise:
> {code}
> public default GraphTraversal dedup(final Scope scope, final String... 
> dedupLabels) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #426: TINKERPOP-1437 Added tests for dedup(Scope,Stri...

[spmallette]

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/426

TINKERPOP-1437 Added tests for dedup(Scope,String...) overload in DedupTest

https://issues.apache.org/jira/browse/TINKERPOP-1437

Pretty simple - just added a couple of tests - but didn't CTR as I'd feel 
better with a couple of extra eyes on this as we've had bad tests slip into the 
suite in the past.  

Runs nicely with `mvn clean install` - doing a `docker/build.sh -t -i -n` 
now. If anything bad happens I'll post back here.

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1437

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/426.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 #426


commit 9666bb3dc2f593b66095b3e764678ccfc35630a5
Author: Stephen Mallette 
Date:   2016-09-16T20:17:33Z

Added tests for dedup(Scope,String...) overload in DedupTest




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[DISCUSS] JIRA cleanup

[Stephen Mallette]

We're hanging around 250 open issues at the moment in JIRA. 28 of those are
"deprecation" issues, so roughly 220 to pay attention to. It's been a while
since we've done any global grooming of the list and I think that as we are
on the way to 3.3.0, it would be good to do a little bit of that.

In the past, we'd had an open hangout for those who wanted to join, so that
we could discuss what to close, schedule, etc. Inevitably, those hangouts
ran well over an hour and now with 200+ issues, I think a hangout won't be
a good way to go through this stuff.

I was thinking that perhaps everyone could independently take a look at
what is either:

1. assigned to them or
2. something they created

and give that JIRA an update? Maybe, you un-assign yourself, bump the
priority, drop in a comment, re-assign the fix version, or bring it to the
attention of the dev list to see if anyone can offer a PR.

For issues you'd like to close, I'd say:

1. if the issue could possibly be of interest to the community (even in a
small way), then start a DISCUSS thread with an explanation as to why you
want to close and use lazy consensus around the decision - you've probably
seen me do those in the past. Example:

https://lists.apache.org/thread.html/6a6e04925c81333ae4ccde3c096c2c439fb2b46756ba10d71dad7e8c@%3Cdev.tinkerpop.apache.org%3E

Then just add a "Web Link" to the DISCUSS thread in the JIRA issue and done!

2. if the issue is something down in the weeds of your area of expertise,
some reminder you created a long time ago that is no longer relevant,
something already implemented, a duplicate, etc - then just close the issue
directly.

If that all sounds good to everyone, it would be cool if we could all take
some time (mostly me, marko, kuppitz as the top JIRA creators right now),
to do a little JIRA grooming by the end of next week.

Thanks,

Stephen

[INFO] Recent changes in has() method signatures

[Daniel Kuppitz]

Hello,

I've recently changes the signatures of our has() methods. Unfortunately I
didn't realize that this change was breaking for some users (those who
arrays as arguments). The old method signatures were all vararg-based:

   - hasId(Object... ids)
   - hasLabel(Object... labels)
   - etc.

...and I mainly changed that to prevent method calls like hasId() with no
args. Since none of our test cases uses arrays, I didn't notice that this
change broke the following queries:

   - __.hasId([1] as Object[])
   - __.hasLabel(["person"] as Object[])
   - etc.

Single entry arrays, that are used as the only arguments, are now treated
as P.eq(arr), but were treated as P.eq(arr[0]) before. I created a PR [1]
with a fix and also added a test that ensures that the new method
signatures behave like the old vararg method signatures (except that they
don't allow you to use no args).

Sorry for any inconvenience.

[1] https://github.com/apache/tinkerpop/pull/425

Cheers,
Daniel

[DISCUSS] running single tests

[Stephen Mallette]

This issue was created a while back:

https://issues.apache.org/jira/browse/TINKERPOP-1076

It presents an option to allow running of a single test in the
structure/process test suite. The solution is beyond anything anyone will
ever do in TinkerPop 3.x (a massive body of work) as it means restructuring
the thousands of tests that we have in a way that I think ends up being
more prone to error than what we have. We do have the environment variable
workaround for running a single test case, and of course marko's classic
method - comment out tests from the process/standard suite that you don't
want to run. :)

I thought I would just bring it to everyone's attention before I closed it,
in case anyone felt differently. Unless there are objections, I'll assume
lazy consensus in three days (Monday, September 19, 2016, 12:30pm EST) and
move forward to close.

[GitHub] tinkerpop pull request #418: Fixed issue in NumberSerializer that could caus...

[leifurhauks]

Github user leifurhauks commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/418#discussion_r79199796
  
--- Diff: 
gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py ---
@@ -181,7 +181,7 @@ class NumberSerializer(GraphSONSerializer):
 def _dictify(self, number):
 if isinstance(number, bool):  # python thinks that 0/1 integers 
are booleans
 return number
-elif isinstance(number, long):
+elif isinstance(number, long) or (number > 2147483647): # in 
python all numbers are int unless specified otherwise
--- End diff --

Maybe the absolute value of the integer should be checked here.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Closed] (TINKERPOP-1330) by()-modulation for where()

[Marko A. Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marko A. Rodriguez closed TINKERPOP-1330.
-

> by()-modulation for where()
> ---
>
> Key: TINKERPOP-1330
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1330
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: Daniel Kuppitz
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.3
>
>
> As discussed in https://issues.apache.org/jira/browse/TINKERPOP-1329, it 
> would be nice to have {{by()}}-modulators for {{where()}}. For example:
> {code}
> g.V().as("a").out().where(gt("a")).by("age") // both a and current ages are 
> selected
> g.V().as("a").out().as("b").where("b",gt("a")).by("age") // both a and b ages 
> are selected
> g.V().as("a").out().as("b").where("b",gt("a")).by("age").by("weight") // 
> where b.age > a.weight
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #418: Fixed issue in NumberSerializer that could caus...

[spmallette]

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/418#discussion_r79189025
  
--- Diff: 
gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py ---
@@ -181,7 +181,7 @@ class NumberSerializer(GraphSONSerializer):
 def _dictify(self, number):
 if isinstance(number, bool):  # python thinks that 0/1 integers 
are booleans
 return number
-elif isinstance(number, long):
+elif isinstance(number, long) or (number > 2147483647): # in 
python all numbers are int unless specified otherwise
--- End diff --

i guess the expectation is a signed integer


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: tinkerpop git commit: Added documentation for the traversal representations of general steps (map, flatMap, filter, sideEffect, branch).

[Marko Rodriguez]

Hey Kuppitz,

Thank you for this. These are very nice additions.

In general people, one of the best things you can do to help is add little 
snippet PRs to our docs.

“This example doesn’t show the full power of this step, I’ll add 
another example.”
“I think there should be more verbage about strategies — why is 
explain() not mentioned and linked to in the traversal strategies section?”
“…”

Like a Wiki, many micro additions will build  up nicely to leave our users a 
full, well-rounded reference doc.

Thanks,
Marko.

http://markorodriguez.com



> On Sep 16, 2016, at 8:27 AM, dkupp...@apache.org wrote:
> 
> Repository: tinkerpop
> Updated Branches:
>  refs/heads/TINKERPOP-1115 [created] 54c08a7ff
> 
> 
> Added documentation for the traversal representations of general steps (map, 
> flatMap, filter, sideEffect, branch).
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
> Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/54c08a7f
> Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/54c08a7f
> Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/54c08a7f
> 
> Branch: refs/heads/TINKERPOP-1115
> Commit: 54c08a7ff68e08f8c1f8b9f850086260e39d1b2d
> Parents: 75baf01
> Author: Daniel Kuppitz 
> Authored: Fri Sep 16 16:26:19 2016 +0200
> Committer: Daniel Kuppitz 
> Committed: Fri Sep 16 16:26:19 2016 +0200
> 
> --
> docs/src/reference/the-traversal.asciidoc | 49 --
> 1 file changed, 30 insertions(+), 19 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/54c08a7f/docs/src/reference/the-traversal.asciidoc
> --
> diff --git a/docs/src/reference/the-traversal.asciidoc 
> b/docs/src/reference/the-traversal.asciidoc
> index 9309e23..3530be3 100644
> --- a/docs/src/reference/the-traversal.asciidoc
> +++ b/docs/src/reference/the-traversal.asciidoc
> @@ -55,27 +55,27 @@ for an anonymous traversal, it is possible to simply 
> write `inE()`. Be aware of
> when using anonymous traversals. For example, `in` and `as` are reserved 
> keywords in Groovy, therefore you must use
> the verbose syntax `__.in()` and `__.as()` to avoid collisions.
> 
> -[[lambda-steps]]
> -Lambda Steps
> -
> -
> -WARNING: Lambda steps are presented for educational purposes as they 
> represent the foundational constructs of the
> -Gremlin language. In practice, lambda steps should be avoided and traversal 
> verification strategies exist to disallow t
> -heir use unless explicitly "turned off." For more information on the 
> problems with lambdas, please read
> -<>.
> +[[general-steps]]
> +General Steps
> +~
> 
> -There are four generic steps by which all other specific steps described 
> later extend.
> +There are five general steps, each having a traversal and a lambda 
> representation, by which all other specific steps described later extend.
> 
> [width="100%",cols="10,12",options="header"]
> |=
> | Step| Description
> -| `map(Function)` | map the traverser to some object of 
> type `E` for the next step to process.
> -| `flatMap(Function)` | map the traverser to an 
> iterator of `E` objects that are streamed to the next step.
> -| `filter(Predicate)` | map the traverser to either true or 
> false, where false will not pass the traverser to the next step.
> -| `sideEffect(Consumer)` | perform some operation on the 
> traverser and pass it to the next step.
> -| `branch(Function)` | split the traverser to all the 
> traversals indexed by the `M` token.
> +| `map(Traversal)`  `map(Function)` | map the 
> traverser to some object of type `E` for the next step to process.
> +| `flatMap(Traversal)`  `flatMap(Function Iterator>)` | map the traverser to an iterator of `E` objects that are 
> streamed to the next step.
> +| `filter(Traversal)`  `filter(Predicate)` | map the 
> traverser to either true or false, where false will not pass the traverser to 
> the next step.
> +| `sideEffect(Traversal)`  `sideEffect(Consumer)` | 
> perform some operation on the traverser and pass it to the next step.
> +| `branch(Traversal)`  `branch(Function)` | split 
> the traverser to all the traversals indexed by the `M` token.
> |=
> 
> +WARNING: Lambda steps are presented for educational purposes as they 
> represent the foundational constructs of the
> +Gremlin language. In practice, lambda steps should be avoided in favor of 
> their traversals 

[jira] [Closed] (TINKERPOP-1442) Killing session should make better attempt to cleanup

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1442.
---
   Resolution: Fixed
Fix Version/s: 3.2.3

> Killing session should make better attempt to cleanup
> -
>
> Key: TINKERPOP-1442
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1442
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.1.4
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.5, 3.2.3
>
>
> When a session is killed it tries to rollback transactions prior to ending 
> the session. If there is a long-run script (or perhaps a queue of jobs) then 
> this close job just gets added to the queue. If that rollback job never 
> executes then the transaction gets orphaned. 
> Graph implementations tend to have their own methods for cleaning up these 
> lingering transactions, but it would be better if the shutdown could occur in 
> an orderly fashion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] 3.3.0 Branching strategy

[Stephen Mallette]

Going back to the dual PRs i referenced:

https://github.com/apache/tinkerpop/pull/412
https://github.com/apache/tinkerpop/pull/413

After a few days of review, I noticed this morning that now that they were
ready for merge, they were conflicted. That means some extra steps because
if I had:

git checkout tp31
git merge TINKERPOP-1442

and resolved the conflict as part of the merge then I would create a fresh
merge commit in tp31 which wouldn't be in master (and that would mean that
the next person to serve up a PR from tp31 to master would end up with that
commit hanging in their PR). Since there is a conflict in the PR, I need to
rebase:

git checkout TINKERPOP-1442
git rebase origin/tp31

At this point, I would complete the rebase and maybe test if necessary, and
then:

git push origin TINKERPOP-1442 --force

Now, git rebase has re-written my commit history which is going to hose my
PR to master, so we just need to clean that up:

git checkout TINKERPOP-1442-master
git reset --hard origin/master
git merge TINKERPOP-1442

and again, re-test if necessary and force push, at which point both PRs can
be merged cleanly.  I'll write all this up in the dev docs to serve as a
reference.


On Tue, Sep 13, 2016 at 8:43 PM, Stephen Mallette 
wrote:

> While we haven't started the tp32 branch yet, I thought I'd do the dual PR
> model for a bug fix that i had on tp31 just to see how it would go. So I
> created two branches using the git commands i specified in my last post on
> this thread:
>
> TINKERPOP-1442
> TINKERPOP-1442-master
>
> and created two PRs from them:
>
> https://github.com/apache/tinkerpop/pull/412
> https://github.com/apache/tinkerpop/pull/413
>
> I think it was helpful to "tag" the target branch in the PR description so
> it was easy to figure out just from the PR list which one you were looking
> at. In this case, this was a pretty easy merge situation as there wasn't
> much divergence between the branches. A nice part about this approach is
> that it forces specific testing of the integration of the code to each
> branch, so even though the code changes are pretty much identical, we are
> assured that some other difference elsewhere between the branches doesn't
> create some havoc we didn't know about.
>
> I suppose the VOTE should still occur on both PRs prior to merging. I
> think it will be confusing any other way.
>
> We will need to take care when merging CTR'd work to not inadvertently
> merge commits destined for master on a PR that is under review. I sense
> that is possible with this model. If you CTR to tp32 and attempt a merge to
> master and get "more" commits than just your CTR, you should take a closer
> look at what it is going on. I think this also means that we need to not
> merge the tp32 PR without also being ready to merge the master PR. They
> should both happen in fairly fast succession of one another.
>
> sorry - boring post - thanks for reading.
>
> On Tue, Sep 13, 2016 at 8:08 AM, Stephen Mallette 
> wrote:
>
>> As there have been no objections, we will go with the PR per branch model
>> when we open the tp32 branch this coming weekend. The flow is pretty
>> simple. Let's say you have work for tp32:
>>
>> 1. git checkout -b  tp32
>> 2. do a bunch of stuff and commit in there
>> 3. git checkout -b  master
>> 4. git merge TINKERPOP-1234
>>
>> That produces two branches, one for tp32 and one for master, from which
>> you can formulate the PRs in GitHub. One issue I thought of this morning
>> was what to do in the case of CTRs where we commit directly to tp32. In
>> those cases, the committer should immediately merge to master as we
>> normally do:
>>
>> git checkout master
>> git merge tp32
>>
>> Presumably, CTR'd work will be a single small commit that is easy to
>> merge. I think we should try to avoid cherry-pick in this model as it
>> re-writes history (i.e. new hash generated for the cherry-picked commit).
>> If we need a commit to stay in tp31 there are ways to do the merge without
>> bringing that specific commit forward. Hope that all makes sense to
>> everyone. I'll probably add something to the dev docs about this model for
>> when we get stated with tp32 next week.
>>
>>
>> On Thu, Sep 8, 2016 at 3:47 PM, Daniel Kuppitz  wrote:
>>
>>> Sounds good to me. It won't necessarily mean much more work, since I
>>> assume
>>> that most branches won't have any merge conflicts.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On Thu, Sep 8, 2016 at 6:36 PM, Stephen Mallette 
>>> wrote:
>>>
>>> > I think 3.3.0 will be a "big" release with many breaking changes as we
>>> > remove deprecation, upgrade certain dependencies, and make other
>>> usability
>>> > improvements. This won't be a release we want to rush as it affords us
>>> an
>>> > opportunity to make a number of things a lot better. I believe that
>>> we'd
>>> > discussed having 3.3.0 as a release for the end of 2016, but the more I
>>> > think 

[jira] [Commented] (TINKERPOP-1442) Killing session should make better attempt to cleanup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15496120#comment-15496120
 ] 

ASF GitHub Bot commented on TINKERPOP-1442:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/413


> Killing session should make better attempt to cleanup
> -
>
> Key: TINKERPOP-1442
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1442
> Project: TinkerPop
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.1.4
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.5
>
>
> When a session is killed it tries to rollback transactions prior to ending 
> the session. If there is a long-run script (or perhaps a queue of jobs) then 
> this close job just gets added to the queue. If that rollback job never 
> executes then the transaction gets orphaned. 
> Graph implementations tend to have their own methods for cleaning up these 
> lingering transactions, but it would be better if the shutdown could occur in 
> an orderly fashion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #413: TINKERPOP-1442 Improved session cleanup on clie...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/413


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #412: TINKERPOP-1442 Improved session cleanup on clie...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/412


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---