Validate distribution looks good along with manual inspection of docs and
testing. Thanks for putting this all together Stephen and for running me
through part of the process this time.
VOTE: +1
--Ted
On Wed, Jul 20, 2016 at 3:42 PM, Stephen Mallette
wrote:
> Thanks Hadrian - I read that sect
This vote is now closed with a total of 4 +1s, no +0s and no -1s. The
results are:
BINDING VOTES:
+1 (X -- Stephen Mallette, Daniel Kuppitz, Dylan Millikin, Ted Wilmes)
0 (0)
-1 (0)
I will wait to officially release 3.1.3 to go alongside the close of vote
on 3.2.1 tomorrow.
Thank you very m
The teat method structure and naming convention is bad. Stephen can help set it
straight.
> On Jul 20, 2016, at 12:40 PM, pluradj wrote:
>
> GitHub user pluradj opened a pull request:
>
>https://github.com/apache/tinkerpop/pull/363
>
>TINKERPOP-1379 remove excess bulk in tail buffer
>
[
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388427#comment-15388427
]
stephen mallette commented on TINKERPOP-1383:
-
+1
> publish-docs.sh might
[
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388360#comment-15388360
]
Daniel Kuppitz commented on TINKERPOP-1383:
---
I think it's better to use a co
Ok, np, its not serious, Postgres is the important one for me anyhow and
it is behaving. I'll investigate how to tell Postgres to cancel the
query. Just stopping the traversal is not quite good enough as every now
and again we have queries on Postgres that persist even if the java
thread dies.
Than
> For every traversal that starts it notifies the caller via the reference
object about the traversal.
that's the tricky bit. you'd have to have some global tracking of spawned
traversals to know that and it would have to be bound to the Thread that
started it I guess. That information isn't going
Well no, the problem is Thread.interrupted() is not reliable. Does not
really matter who the caller is, GremlinServer or other.
Just about every 3rd party library I can see might reset the flag
meaning that the check will randomly return false or true. Something as
trivial as a logger might even re
[
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette updated TINKERPOP-1383:
Summary: publish-docs.sh might publish to current too early (was:
publish-docs.
stephen mallette created TINKERPOP-1383:
---
Summary: publish-docs.sh might publish to current to early
Key: TINKERPOP-1383
URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
Project: TinkerP
Your way made me think that if you wrote your traversal like that, you
would return the side-effects twice - once in your traversal as part of the
standard result and then again as a side-effect. Not sure what that means
- just a thought.
While I'm thinking thoughts that may or may not be obvious
thanks for all that pieter. the primary reason for traversal interruption
in the first place was so that gremlin server would have a chance to kill
traversals that were running too long. Without a solution to that problem,
I'm not sure what to do here. just tossing ideas around - could we still
che
I just did a global Intellij search in the Sqlg project.
HSQLDB has 13 catch (InterruptedException e) clauses. All of them
swallows the exception and none resets the interrupt flag.
Postgresql jdbc driver has 3 catch (InterruptedException e) clauses. 2
swallows the exception without resetting the
If you really want to have your result and your side-effects returned by a
single request, you could do something like this:
gremlin>
g.V(1,2,4).aggregate("names").by("name").aggregate("ages").by("age")*.fold().as("data").select("data",
"names", "ages")*
==>[data:[v[1], v[2], v[4]], names:[marko,
I don't recall all the issues with doing traversal interruption with a
flag. I suppose it could work in the same way that thread interruption
works now. I will say that I'm hesitant to say that we should change this
on the basis of this being a problem general to databases as we've only
seen in so
As we look to build out GLVs and expand Gremlin into other programming
languages, one of the important aspects of doing this should be to consider
consistency across GLVs. We should try to prevent capabilities of Java from
being lost in Python, JS, etc.
As we look at both RemoteGraph in Java and g
[
https://issues.apache.org/jira/browse/TINKERPOP-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1382.
---
Resolution: Duplicate
Assignee: stephen mallette
I tried to provide an examp
[
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387523#comment-15387523
]
stephen mallette commented on TINKERPOP-1380:
-
I'm good with breaking this
[
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387444#comment-15387444
]
Daniel Kuppitz commented on TINKERPOP-1380:
---
A simple test case we could add
[
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387407#comment-15387407
]
Daniel Kuppitz edited comment on TINKERPOP-1380 at 7/21/16 9:08 AM:
[
https://issues.apache.org/jira/browse/TINKERPOP-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387407#comment-15387407
]
Daniel Kuppitz commented on TINKERPOP-1380:
---
I inspected the side-effects in
21 matches
Mail list logo