Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/425
---
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 e
+1 I find this to be way more explicit. Kinda got tripped by this a while
back.
On Tue, Sep 20, 2016 at 3:38 PM, Daniel Kuppitz wrote:
> +1
>
> On Tue, Sep 20, 2016 at 3:35 PM, Marko Rodriguez
> wrote:
>
> > Hi,
> >
> > I was thinking that store() and aggregate() should simply be “store().”
> >
GitHub user spmallette opened a pull request:
https://github.com/apache/tinkerpop/pull/429
TINKERPOP-1457 Fixed Lambda serialization in bytecode for java/groovy.
https://issues.apache.org/jira/browse/TINKERPOP-1457
Standard tests using lambdas are ignored which is why we did
[
https://issues.apache.org/jira/browse/TINKERPOP-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15507827#comment-15507827
]
ASF GitHub Bot commented on TINKERPOP-1457:
---
GitHub user spmallette opened a
David M. Brown created TINKERPOP-1458:
-
Summary: Gremlin Server doesn't return confirmation upon Traversal
OpProcessor "close" op
Key: TINKERPOP-1458
URL: https://issues.apache.org/jira/browse/TINKERPOP-1458
stephen mallette created TINKERPOP-1457:
---
Summary: Groovy Lambdas for remote traversals not serializable
Key: TINKERPOP-1457
URL: https://issues.apache.org/jira/browse/TINKERPOP-1457
Project: Tin
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/425
good: "all `has()` method overloads behave like before"
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
---
If your project is set up for it, you can reply to this ema
Anyone interested in seeing a Graph.addVertex(Map) overload?
https://issues.apache.org/jira/browse/TINKERPOP-1174
I don't imagine there would be any change to addV() in this case. I'm
thinking that we wouldn't likely use this method internally and so it would
more be something for user convenienc
[
https://issues.apache.org/jira/browse/TINKERPOP-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1076.
---
Resolution: Won't Fix
Assignee: stephen mallette
Closed given mailing list d
I think these are the ones that contain logic and are dynamically sorta
driven:
ElementFeatures.willAllowId(Object)
VertexPropertyFeatures.willAllowId(Object)
VertexFeatures.getCardinality(String)
I was thinking that some graphs might return static values for these in
which case caching would wor
I would also like to add that for every CHANGELOG entry some consideration
should be taken to determine if our "upgrade documentation" needs an entry
as well. If something is a breaking change, interesting feature or just a
change of behavior that might trip people up when they upgrade, it will be
Nice discussion thread, Stephen. I've tinkered around minimally with
writing a graph implementation, so hopefully we'll get more feedback from
others. From what I have done, +1 on killing @OptOut test annotations. They
seem out of place on the Graph impl class.
You mentioned "there is at least one
Hi,
I’m noticing that we are merging lots of PRs, but we are not updating the
CHANGELOG accordingly. If you are submitting PRs, please be sure to add
CHANGELOG notes. Moreover, if you are reviewing a PR, be sure to check for
CHANGELOG notes.
Thanks,
Marko.
http://markorodriguez.com
[
https://issues.apache.org/jira/browse/TINKERPOP-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1437.
---
Resolution: Done
Assignee: stephen mallette
Fix Version/s: 3.2.3
>
[
https://issues.apache.org/jira/browse/TINKERPOP-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1451.
---
Resolution: Fixed
Assignee: stephen mallette
Fix Version/s: 3.2.3
+1
On Tue, Sep 20, 2016 at 3:35 PM, Marko Rodriguez
wrote:
> Hi,
>
> I was thinking that store() and aggregate() should simply be “store().”
>
> store() -> store(local)
> aggregate() -> store(global)
>
> Or:
>
> aggregate() -> barrier().store()
>
> Random tho
Hi,
I was thinking that store() and aggregate() should simply be “store().”
store() -> store(local)
aggregate() -> store(global)
Or:
aggregate() -> barrier().store()
Random thoughts…
Marko.
http://markorodriguez.com
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/428
I assume #427 doesn't need 120cef6 ? I don't think the dual merge commits
hurt anything from the git history perspective. I assume that you merged in
TINKERPOP-927, realized you needed someth
Github user PommeVerte commented on the issue:
https://github.com/apache/tinkerpop/pull/424
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
[
https://issues.apache.org/jira/browse/TINKERPOP-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505970#comment-15505970
]
ASF GitHub Bot commented on TINKERPOP-1451:
---
Github user PommeVerte commente
Github user PommeVerte commented on the issue:
https://github.com/apache/tinkerpop/pull/418
What's the test status on this GLV? Could it be possible to add tests for
this case?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as w
Github user PommeVerte commented on the issue:
https://github.com/apache/tinkerpop/pull/425
Docs were clear, change is straightforward and tested this manually:
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.
22 matches
Mail list logo