go 查询语句中如何把第一个跳的结果传递通过管道传递到fetch中

A - Relation → B
C - Relation ->D
这个方法我试过,但是这样就会产生更多的结果, 比如上述的D 就会额外产生。
其实只需要A - Relation → B 的关系,根据C 的publish_time 排序

不会啊,第二个GO语句只用来获取起点属性啊

1 个赞

开始这么多数据量


后来这么多

现在的图关系是
A - Relation - B
Relation 上有个keyno == C 的vid

并不是说,需要从Relation 的keyno 上去出发才能找到C
如果合法,应该是下面的写法 才是需要的结果

GO FROM 3436443372514187470 OVER Relation BIDIRECT WHERE Relation.name=="XXX”  \
YIELD  $^.Company.name, $$.Company.keyno as keyno, \
    $$.Company.name as name, Relation.keyno as keyno2 | 
fetch prop on TagB hash($-.keyno2) yield properties(vertex).publish_time as t, $-.name as name,
$-.keyno as keyno, $-.keyno2 as keyno2 |   order by $-.t

GO FROM hash($-.keyno2) OVER * YIELD DISTINCT $-.name, $-.keyno, properties($$).publish_time as t

加个distinct呢

我觉得可能我还是没讲清楚。
hash($-.keyno2) 这个点是有publish_time 的,但是从这个点出发的到达的点 不一定有publish_time
现在是希望根据hash($-.keyno2) 的属性publish_time 排序,不是根据从他出发得到的点排序。

GO FROM hash($-.keyno2) OVER * YIELD DISTINCT $-.name, $-.keyno, properties($^).publish_time as t
如果是起点,改成这样就可以了

1 个赞

非常感谢,结果是正确的,明白怎么回事了。
这样是不是还是会有 正常的从vid 向外遍历的耗时,只是目标的点舍弃了?

1 个赞

不会,只是取了起点

好的,感谢

学习了学习了,:person_kneeling:t2:,这是把 GO 用做能传递管道信息的 FETCH 了,颠覆了我的认知 Σ(⊙▽⊙”a

1 个赞

是的,我开始试了这个方式,但是结果数量不对,没太注意值是一样的,以为目标点一定会出来呢。害

2 个赞

:+1:t2:,差一点,这下让我们都学到了。
我压根都没想到 GO 一下,总想着GO需要跳一跳,太昂贵了,没想到只返回起点的计划也不会去获得邻居,也没想到这么搞前边的列都能输出。

2 个赞

哈哈,学习了学习了,:man_kneeling:

1 个赞

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。