Re: failing optional and order by gremlin
OK got it.
Thanks for the help.
Cheers,
Pieter
On 11/02/2017 16:46, Daniel Kuppitz wrote:
> This looks like a bug in 3.2.3. It's clearly expected to fail, since by()
> modulators should always fail if the traverser can't emit a value. What you
> actually want to do is this:
>
> gremlin> g.traversal().V(a1.id()).optional(
> ..1> outE("ab").as("e").otherV().as("vb").optional(
> ..2> outE("bc").as("e").otherV().as("vc"))).
> ..3> order().by(select(first, "e").by("order")).
> ..4> by(select(last, "e").by("order")).values("name")
> ==>b3
> ==>b2
> ==>c3
> ==>c2
> ==>c1
>
> Not related to your problem, but I thought I should point that out: don't
> use otherV() when you know the direction.
>
> g.traversal().V(a1.id()).optional(
> outE("ab").as("e").inV().as("vb").optional(
> outE("bc").as("e").inV().as("vc"))).
> order().by(select(first, "e").by("order")).
> by(select(last, "e").by("order")).values("name")
>
> Also, some labels are redundant in this particular traversal; get rid of
> them:
>
> g.traversal().V(a1.id()).optional(
> outE("ab").as("e").inV().optional(
> outE("bc").as("e").inV())).
> order().by(select(first, "e").by("order")).
> by(select(last, "e").by("order")).values("name")
>
> Oh, and there's something else: The query would fail if there wouldn't be a
> single "ab" edge. If you want to take this into account, do:
>
> g.traversal().V(a1.id()).optional(
> outE("ab").as("e").inV().optional(
> outE("bc").as("e").inV())).
> order().by(coalesce(select(first, "e").by("order"), constant(0))).
> by(coalesce(select(last, "e").by("order"),
> constant(0))).values("name")
>
> And finally, pointing out the obvious: don't create a new traversal source
> for every query.
>
> That's it.
>
> Cheers,
> Daniel
>
>
> On Sat, Feb 11, 2017 at 3:03 PM, pieter-gmail
> wrote:
>
>> Hi,
>>
>> The following query no longer works on 3.2.4
>>
>> @Test
>> public void testOptionalWithOrderBy() {
>> final TinkerGraph g = TinkerGraph.open();
>> Vertex a1 = g.addVertex(T.label, "A", "name", "a1");
>> Vertex b1 = g.addVertex(T.label, "B", "name", "b1");
>> Vertex b2 = g.addVertex(T.label, "B", "name", "b2");
>> Vertex b3 = g.addVertex(T.label, "B", "name", "b3");
>> Vertex c1 = g.addVertex(T.label, "C", "name", "c1");
>> Vertex c2 = g.addVertex(T.label, "C", "name", "c2");
>> Vertex c3 = g.addVertex(T.label, "C", "name", "c3");
>> a1.addEdge("ab", b1, "order", 3);
>> a1.addEdge("ab", b2, "order", 2);
>> a1.addEdge("ab", b3, "order", 1);
>> b1.addEdge("bc", c1, "order", 3);
>> b1.addEdge("bc", c2, "order", 2);
>> b1.addEdge("bc", c3, "order", 1);
>> GraphTraversal traversal = g.traversal().V(a1.id
>> ())
>> .optional(
>> __.outE("ab").as("ab").otherV().as("vb")
>> .optional(
>>
>> __.outE("bc").as("bc").otherV().as("vc")
>> )
>> )
>> .order().by(__.select("ab").by("order"),
>> Order.incr).by(__.select("bc").by("order"), Order.incr);
>> while (traversal.hasNext()) {
>> System.out.println(traversal.next().value("name"));
>> }
>> }
>>
>> On 3.2.3 it returns
>>
>> b3
>> b2
>> c3
>> c2
>> c1
>>
>> On 3.2.4 it throws the following exception,
>>
>> java.lang.IllegalArgumentException: The provided traverser does not map
>> to a value: v[6]->[SelectOneStep(bc,value(order))]
>> at
>> org.apache.tinkerpop.gremlin.process.traversal.util.TraversalUtil.apply(
>> TraversalUtil.java:45)
>> at
>> org.apache.tinkerpop.gremlin.process.traversal.step.map.OrderGlobalStep.
>> createProjectedTraverser(OrderGlobalStep.java:155)
>> at
>> org.apache.tinkerpop.gremlin.process.traversal.step.map.OrderGlobalStep.
>> processAllStarts(OrderGlobalStep.java:74)
>> at
>> org.apache.tinkerpop.gremlin.process.traversal.step.util.
>> CollectingBarrierStep.processNextStart(CollectingBarrierStep.java:108)
>> at
>> org.apache.tinkerpop.gremlin.process.traversal.step.util.
>> AbstractStep.hasNext(AbstractStep.java:143)
>> at
>> org.apache.tinkerpop.gremlin.process.traversal.util.
>> DefaultTraversal.hasNext(DefaultTraversal.java:184)
>>
>> Has the semantics changed or is it a bug?
>>
>> Thanks
>> Pieter
>>
>>
[jira] [Created] (TINKERPOP-1630) Consider adding by(Object value)
Daniel Kuppitz created TINKERPOP-1630:
-
Summary: Consider adding by(Object value)
Key: TINKERPOP-1630
URL: https://issues.apache.org/jira/browse/TINKERPOP-1630
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.3.0
Reporter: Daniel Kuppitz
I often find myself writing stuff like {{sack(assign).by(constant(1))}}. Would
be nice if I could simply do {{sack(assign).by(1)}}.
{noformat}
public default GraphTraversal by(final Object value) {
return by(__.constant(value));
}
{noformat}
Downside: Might lead to confusion with Strings.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
Re: failing optional and order by gremlin
This looks like a bug in 3.2.3. It's clearly expected to fail, since by()
modulators should always fail if the traverser can't emit a value. What you
actually want to do is this:
gremlin> g.traversal().V(a1.id()).optional(
..1> outE("ab").as("e").otherV().as("vb").optional(
..2> outE("bc").as("e").otherV().as("vc"))).
..3> order().by(select(first, "e").by("order")).
..4> by(select(last, "e").by("order")).values("name")
==>b3
==>b2
==>c3
==>c2
==>c1
Not related to your problem, but I thought I should point that out: don't
use otherV() when you know the direction.
g.traversal().V(a1.id()).optional(
outE("ab").as("e").inV().as("vb").optional(
outE("bc").as("e").inV().as("vc"))).
order().by(select(first, "e").by("order")).
by(select(last, "e").by("order")).values("name")
Also, some labels are redundant in this particular traversal; get rid of
them:
g.traversal().V(a1.id()).optional(
outE("ab").as("e").inV().optional(
outE("bc").as("e").inV())).
order().by(select(first, "e").by("order")).
by(select(last, "e").by("order")).values("name")
Oh, and there's something else: The query would fail if there wouldn't be a
single "ab" edge. If you want to take this into account, do:
g.traversal().V(a1.id()).optional(
outE("ab").as("e").inV().optional(
outE("bc").as("e").inV())).
order().by(coalesce(select(first, "e").by("order"), constant(0))).
by(coalesce(select(last, "e").by("order"),
constant(0))).values("name")
And finally, pointing out the obvious: don't create a new traversal source
for every query.
That's it.
Cheers,
Daniel
On Sat, Feb 11, 2017 at 3:03 PM, pieter-gmail
wrote:
> Hi,
>
> The following query no longer works on 3.2.4
>
> @Test
> public void testOptionalWithOrderBy() {
> final TinkerGraph g = TinkerGraph.open();
> Vertex a1 = g.addVertex(T.label, "A", "name", "a1");
> Vertex b1 = g.addVertex(T.label, "B", "name", "b1");
> Vertex b2 = g.addVertex(T.label, "B", "name", "b2");
> Vertex b3 = g.addVertex(T.label, "B", "name", "b3");
> Vertex c1 = g.addVertex(T.label, "C", "name", "c1");
> Vertex c2 = g.addVertex(T.label, "C", "name", "c2");
> Vertex c3 = g.addVertex(T.label, "C", "name", "c3");
> a1.addEdge("ab", b1, "order", 3);
> a1.addEdge("ab", b2, "order", 2);
> a1.addEdge("ab", b3, "order", 1);
> b1.addEdge("bc", c1, "order", 3);
> b1.addEdge("bc", c2, "order", 2);
> b1.addEdge("bc", c3, "order", 1);
> GraphTraversal traversal = g.traversal().V(a1.id
> ())
> .optional(
> __.outE("ab").as("ab").otherV().as("vb")
> .optional(
>
> __.outE("bc").as("bc").otherV().as("vc")
> )
> )
> .order().by(__.select("ab").by("order"),
> Order.incr).by(__.select("bc").by("order"), Order.incr);
> while (traversal.hasNext()) {
> System.out.println(traversal.next().value("name"));
> }
> }
>
> On 3.2.3 it returns
>
> b3
> b2
> c3
> c2
> c1
>
> On 3.2.4 it throws the following exception,
>
> java.lang.IllegalArgumentException: The provided traverser does not map
> to a value: v[6]->[SelectOneStep(bc,value(order))]
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.TraversalUtil.apply(
> TraversalUtil.java:45)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.OrderGlobalStep.
> createProjectedTraverser(OrderGlobalStep.java:155)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.OrderGlobalStep.
> processAllStarts(OrderGlobalStep.java:74)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.
> CollectingBarrierStep.processNextStart(CollectingBarrierStep.java:108)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.
> AbstractStep.hasNext(AbstractStep.java:143)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.
> DefaultTraversal.hasNext(DefaultTraversal.java:184)
>
> Has the semantics changed or is it a bug?
>
> Thanks
> Pieter
>
>
RE: failing optional and order by gremlin
Hi,
The following query no longer works on 3.2.4
@Test
public void testOptionalWithOrderBy() {
final TinkerGraph g = TinkerGraph.open();
Vertex a1 = g.addVertex(T.label, "A", "name", "a1");
Vertex b1 = g.addVertex(T.label, "B", "name", "b1");
Vertex b2 = g.addVertex(T.label, "B", "name", "b2");
Vertex b3 = g.addVertex(T.label, "B", "name", "b3");
Vertex c1 = g.addVertex(T.label, "C", "name", "c1");
Vertex c2 = g.addVertex(T.label, "C", "name", "c2");
Vertex c3 = g.addVertex(T.label, "C", "name", "c3");
a1.addEdge("ab", b1, "order", 3);
a1.addEdge("ab", b2, "order", 2);
a1.addEdge("ab", b3, "order", 1);
b1.addEdge("bc", c1, "order", 3);
b1.addEdge("bc", c2, "order", 2);
b1.addEdge("bc", c3, "order", 1);
GraphTraversal traversal = g.traversal().V(a1.id())
.optional(
__.outE("ab").as("ab").otherV().as("vb")
.optional(
__.outE("bc").as("bc").otherV().as("vc")
)
)
.order().by(__.select("ab").by("order"),
Order.incr).by(__.select("bc").by("order"), Order.incr);
while (traversal.hasNext()) {
System.out.println(traversal.next().value("name"));
}
}
On 3.2.3 it returns
b3
b2
c3
c2
c1
On 3.2.4 it throws the following exception,
java.lang.IllegalArgumentException: The provided traverser does not map
to a value: v[6]->[SelectOneStep(bc,value(order))]
at
org.apache.tinkerpop.gremlin.process.traversal.util.TraversalUtil.apply(TraversalUtil.java:45)
at
org.apache.tinkerpop.gremlin.process.traversal.step.map.OrderGlobalStep.createProjectedTraverser(OrderGlobalStep.java:155)
at
org.apache.tinkerpop.gremlin.process.traversal.step.map.OrderGlobalStep.processAllStarts(OrderGlobalStep.java:74)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.CollectingBarrierStep.processNextStart(CollectingBarrierStep.java:108)
at
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:184)
Has the semantics changed or is it a bug?
Thanks
Pieter
Re: [VOTE] TinkerPop 3.2.4 Release
website passes linkchecker. my app passes all tests. VOTE +1 Robert Dale On Fri, Feb 10, 2017 at 9:14 AM, Stephen Mallette wrote: > i think it's on schedule still. pieter sounded like he needed a little > extra time, but given the nature of the issue he described it didn't seem > like that would ultimately turn up something run afoul in the TinkerPop > side of things, so my personal inclination would be to close vote when > posted and release. on the other hand, the vote closes on a saturday, which > means that unless jason intends to do release work on the weekend, there's > not much point to closing the vote on saturday and pieter can have some > extra time. Anyway, I'll leave that up to Jason to coordinate with Ted as > we traditionally release all our lines of code at once. Once they do close > vote and release the artifacts, it will take up to 24 hours for apache > infrastructure to sync the releases to all the mirrors, so everything is > usually available the day after the vote closes. > > as for voting, every vote counts - though PMC votes are the ones that are > technically "binding" for purpose of a release (in apache terms we need a > "majority approval"[1] to put the release out the door). Now, if any vote, > non-binding or binding came in as -1, we would take that fairly seriously, > discuss it and depending on circumstances could scrap/delay the release. > Testing releases and voting is an excellent and easy way to contribute to > TinkerPop. > > [1] http://apache.org/foundation/glossary.html#MajorityApproval > > > On Fri, Feb 10, 2017 at 8:47 AM, Paul A. Jackson > wrote: > > > I'm looking for some insight for when 3.2.4 will release. It looks like > > voting closes tomorrow. Is that on schedule, and if so what's a typical > ETA > > for binaries to be posted? > > > > I don't know if my vote counts, but FTW! > > > > VOTE: +1 > > > > Thanks, > > -Paul > > > > > > -Original Message- > > From: Stephen Mallette [mailto:spmalle...@gmail.com] > > Sent: Friday, February 10, 2017 7:03 AM > > To: dev@tinkerpop.apache.org > > Subject: Re: [VOTE] TinkerPop 3.2.4 Release > > > > validate-distribution.sh was good for me - thanks for doing all the work > > on this one Jason. nice job > > > > VOTE: +1 > > > > On Fri, Feb 10, 2017 at 1:22 AM, Ted Wilmes wrote: > > > > > Release and docs looks good to me. > > > > > > Validating source distribution > > > > > > * downloading Apache TinkerPop 3.2.4 (apache-tinkerpop-3.2.4-src. > zip)... > > > OK > > > * validating signatures and checksums ... > > > * PGP signature ... OK > > > * MD5 checksum ... OK > > > * SHA1 checksum ... OK > > > * unzipping Apache TinkerPop 3.2.4 ... OK > > > * building project ... OK > > > > > > > > > VOTE: +1 > > > > > > Thanks, > > > Ted > > > > > > On Thu, Feb 9, 2017 at 12:32 PM, pieter-gmail > > > > > > wrote: > > > > > > > Ok, however I did test on the 3.2.4-SNAPSHOT immediately after > > > > Jason's email on the 2/2/2017 and those changes were not there. > > > > They are there now but there was a SNAPSHOT release on the > > > > 08/02/2017 so things changed. > > > > Anyhow that might just be some SNAPSHOT confusion thing. > > > > > > > > Next time I'll pull the code and build it manually to make sure. > > > > > > > > Thanks > > > > Pieter > > > > > > > > > > > > > > > > On 09/02/2017 22:27, Marko Rodriguez wrote: > > > > > Hi, > > > > > > > > > >> The significant change is > > > > >> ffe1b4c Marko A. Rodriguez on 2016/11/15 > > > > >> at > > > > 12:44 AM > > > > > Ah yea. Thats different from what I thought you had issue with — > > > > has-containers and arrays/collections handling. > > > > > > > > > >> I don't have a problem with the changes just that is quite a > > > > >> refactor > > > on > > > > >> my side as it changes the structure of the HasSteps and its > > > > >> HasContainers. I had made some assumptions around how HasSteps > > > > >> and HasContainers look when optimizing. > > > > > Yea, it “folds left” now so you don’t have to walk over > has()-chains. > > > > > > > > > >> The change is quite old but somehow it was not present in the > > > > >> 3.2.4-SNAPSHOT I tested on it when the code freeze announcement > > > > >> was made. Not sure what happened there but alas its not giving me > > > > >> enough time to get things working again. > > > > > I would say don’t wait till releases to test Sqlg. In principle, > > > > > you > > > > should VOTE on every PR by building and testing the changes against > > Sqlg. > > > > That is where you can make a huge contribution. > > > > > > > > > >> So I am not voting negative just requesting a weekend, if > > > > >> possible, to get through the refactor. > > > > > Again, PR awareness, not release awareness. > > > > > > > > > > Marko. > > > > > > > > > > http://markorodriguez.com > > > > > > > > > > > > > > >> Cheers > > > > >> Pieter > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> "added TraversalHelper.addHasContainer() on 2016/11/15 > > > > >> > > > >
