[jira] [Created] (TINKERPOP-1391) count step
Arik Cohen created TINKERPOP-1391:
-
Summary: count step
Key: TINKERPOP-1391
URL: https://issues.apache.org/jira/browse/TINKERPOP-1391
Project: TinkerPop
Issue Type: Bug
Reporter: Arik Cohen
Graph g = TinkerGraph.open();
g.addVertex(T.label,"GROUP","name","Acme");
List list = g.traversal()
.V()
.hasLabel("GROUP")
.where(__.outE().hasLabel("PART_OF").count().is(0))
.toList();
Assert.assertEquals(1, list.size()); // actual size is 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1391) issue with where filter
[
https://issues.apache.org/jira/browse/TINKERPOP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arik Cohen updated TINKERPOP-1391:
--
Summary: issue with where filter (was: count step)
> issue with where filter
> ---
>
> Key: TINKERPOP-1391
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1391
> Project: TinkerPop
> Issue Type: Bug
>Reporter: Arik Cohen
>
> Graph g = TinkerGraph.open();
> g.addVertex(T.label,"GROUP","name","Acme");
>
> List list = g.traversal()
>.V()
>.hasLabel("GROUP")
>
> .where(__.outE().hasLabel("PART_OF").count().is(0))
>.toList();
>
> Assert.assertEquals(1, list.size()); // actual size is 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [DISCUSS] Download Page
I assume everyone is cool with making the Download Page live at this point as there's been no other feedback in the last few days. I'll probably make some adjustments to the web site tomorrow to bring it online publicly. On Mon, Jul 25, 2016 at 7:33 AM, Stephen Mallette wrote: > I updated the downloads page some more: > > + tweaked the date format a bit to "really" match the rest of the site > (which is still inconsistent in other places like changelog - dah) > + added a "verifying downloads" section which talks about GPG/PGP/etc. > > http://tinkerpop.apache.org/downloads.html > > > > > On Fri, Jul 22, 2016 at 3:53 PM, Stephen Mallette > wrote: > >> Good feedback Robert/Jason. >> >> Updated: >> >> http://tinkerpop.apache.org/downloads.html >> >> Added documentation and included some descriptors to current releases. >> Didn't change the date format for now - that's the format we use everywhere >> around "release" so didn't want to muck with that at this point. >> >> >> >> On Fri, Jul 22, 2016 at 3:36 PM, Robert Dale wrote: >> >>> Stephen, I think what Sebb might be getting at is that some things >>> should be spelled out even if they are obvious to some. I agree with >>> this. >>> >>> 3.2.1 (latest, stable) >>> 3.1.3 (bug fixes only) >>> >>> I think the dates should be in ISO8601 format. -MM-DD >>> >>> Otherwise, I think it looks very good. >>> >>> -- >>> Robert Dale >>> >>> On Fri, Jul 22, 2016 at 2:51 PM, Jason Plurad wrote: >>> > +1 looks great. >>> > >>> > Link to the documentation, maybe next to the release notes link, would >>> be >>> > useful too. >>> > >>> > -- Jason >>> > >>> > On Fri, Jul 22, 2016 at 2:07 PM, Stephen Mallette < >>> spmalle...@gmail.com> >>> > wrote: >>> > >>> >> I think it might be a good idea to include a "Download Page" on our >>> web >>> >> site. It would let us better list the versions we have out there and >>> would >>> >> get us better in line with Apache Infrastructure - for example: >>> >> >>> >> https://issues.apache.org/jira/browse/TINKERPOP-1255 >>> >> >>> >> I'm also seeing that we yet have spots where we dont' link to the >>> mirror >>> >> system. And finally, it would be nice to have a "generic" download >>> page >>> >> where we could point external links to - like the new "documentation" >>> >> feature in StackOverflow (right now it's sorta hardcoded to the mirror >>> >> which isn't so good because we'll have to change that all the time). >>> >> >>> >> I quickly took a swipe at such a page: >>> >> >>> >> http://tinkerpop.apache.org/downloads.html >>> >> >>> >> It is NOT "linked to" by anything at this point so it is "hidden". I >>> just >>> >> wanted to have something that everyone could look at to get the idea >>> of >>> >> what such a page might look like. >>> >> >>> >> Thoughts? >>> >> >>> >> Thanks, >>> >> >>> >> Stephen >>> >> >>> >> >> >
Re: [DISCUSS] Returning Side Effects
I have a rough cut of "returning side-effects" working on TINKERPOP-1278
branch. I didn't bother making this change for REST at this time as I felt
like it was more important and useful to have it run for websockets/NIO as
the drivers that would ultimately power a RemoteConnection are generally
written for that interface.
gremlin> graph = RemoteGraph.open('conf/remote-graph.properties')
==>remotegraph[DriverServerConnection-localhost/127.0.0.1:8182 [graph=g]]
gremlin> g = graph.traversal()
==>graphtraversalsource[remotegraph[DriverServerConnection-localhost/
127.0.0.1:8182 [graph=g]], standard]
gremlin> t = g.V(1).aggregate('a').outE("knows").aggregate("b").inV()
==>v[2]
==>v[4]
gremlin> t.getSideEffects().get('a')
==>v[1]
gremlin> t.getSideEffects().get('b')
==>e[7][1-knows->2]
==>e[8][1-knows->4]
It was more effort than i expected to get this to work mostly because of my
attempts to do it all without breaking change. It was also interesting (and
nice) to see that the protocol didn't need to change structurally for this
to work, however, drivers will need to adjust a bit to deal with the
side-effects now streaming back following results. Note that this only
matters for those drivers who support submitting Traversals as Bytecode
(which I assume is "none" of them) and existing script submissions should
still have he same behavior and thus a terminating stream with the final
result (side effects left on the server as always).
To allow for side-effects to come back I added two pieces of metadata to a
ResponseMessage:
1. sideEffect - which is the value of the side effect key. for instance in
the above example, there would be values for "a" and "b" at different
points in the stream
2. aggregateTo - which will be one of map, list, bulkset, or none. the
significance here is that we needed a way to to tell the client how a batch
of results should be re-assembled. recall that Gremlin Server iterates
everything. If you return a String it puts the String into an Iterator for
the response. There needed to be a way to say that a particular sideeffect
was converted to iterator so that it could be re-assembled (or not) to what
the original type was.
As for the streaming model, Gremlin Server iterates the results first and
then the side effects by key. Recall that a ResponseMessage batches up
results returned from the server based on iteration size. I've arranged it
so that a ResponseMessage will never mix results with side effects or one
side-effect key with another key. In this way, it's easy to tie the
sideEffect/aggregateTo values to the data within the message. That made it
pretty easy for me to assemble the stream of side-effects into something
useful on the client side.
There is still a lot to do here:
1. Lots of code cleanup to say the least - Some of the basic interfaces,
classes, etc that i added may see some change as i review with a fresh mind
tomorrow.
2. I'd like to make it optional to return side-effects so that drivers or
users can choose to opt-out of the expense of sending that information back
if it isn't needed somehow
3. Piggy-backing on 2, as mentioned earlier in this thread, i think it
would be nice if you could actively state as a user which side-effects you
wanted sent back when you submit the traversal. not sure where that would
be specified right now given the way everything is hooked together.
4. Documentation is non-existent at this point beyond what i've tried to
lay out in this thread so I gotta get to that when all the change settles
down. I assume that won't happen until Marko gets back from his time off as
I suspect he'll think of a few extra things to do in making this all work
well.
Anyway, please let me know if there are any thoughts on this approach.
On Fri, Jul 22, 2016 at 6:24 PM, Stephen Mallette
wrote:
> Yes, I expected to return results first and then stream the side-effects.
>
> On Fri, Jul 22, 2016 at 5:05 PM, Dylan Millikin
> wrote:
>
>> > Perhaps nicer than doing all that trickery with transactions would be to
>> self-detach the vertex ahead of time
>>
>> This was the original idea, I never dove too deep into it as the
>> sideEffects were applied mid traversal and extra filtering/SEs still had
>> to
>> occur. I wasn't sure it was actually possible and the transaction hack
>> allowed me to move on.
>>
>> As for the GLV limitations, it's mostly going to be network overhead.
>> Unfortunately one round trip with the server is costly and I know that
>> we've ended up having to be creative in order to limit the round trips by
>> concatenating scripts for each query. A GLV approach would need some
>> careful planing and probably a multiline byteCode feature. But I digress
>> that's not what this thread is about.
>>
>> In the spirit of GLVs returning side effects how would your original
>> proposition stream over the network? Would you get all data first and then
>> SE? I'm guessing you would want to stream the SEs as well.
>>
>> On Fri, Jul 22, 2016 at 4:42 PM, Step
[jira] [Created] (TINKERPOP-1390) IdentityRemoveStrategyTest fails randomly
stephen mallette created TINKERPOP-1390:
---
Summary: IdentityRemoveStrategyTest fails randomly
Key: TINKERPOP-1390
URL: https://issues.apache.org/jira/browse/TINKERPOP-1390
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.2.1
Reporter: stephen mallette
Priority: Minor
Fix For: 3.2.2
This test fails for me on different occasions - enough for me to have noticed
it happening:
{code}
shouldBeFaster(org.apache.tinkerpop.gremlin.process.traversal.strategy.optimization.IdentityRemovalStrategyTest$PerformanceTest)
Time elapsed: 1.857 sec <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.tinkerpop.gremlin.process.traversal.strategy.TraversalStrategyPerformanceTest.shouldBeFaster(TraversalStrategyPerformanceTest.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #365: Tp31: Minor word and link cleanup
Github user PommeVerte commented on the issue: https://github.com/apache/tinkerpop/pull/365 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. ---
[GitHub] tinkerpop issue #362: Minor word and link cleanup
Github user PommeVerte commented on the issue: https://github.com/apache/tinkerpop/pull/362 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. ---
[GitHub] tinkerpop issue #365: Tp31: Minor word and link cleanup
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/365 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. ---
[GitHub] tinkerpop issue #362: Minor word and link cleanup
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/362 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. ---
[GitHub] tinkerpop issue #364: tweaks in gremlin language variants doc
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/364 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. ---
